You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As organizations generate an increasing number of data events, there is a growing need for detailed insights into the adoption and engagement metrics of the internal developer portal. These insights help platform engineers make data-driven decisions to improve its performance, usability, and translate them into actionable insights.
You can use Adoption Insights in {product} to visualize key metrics and trends to get information about the usage of {product-short} in your organization. The information provided by Adoption Insights in {product-short} helps you pinpoint areas of improvement, highlights popular features, and evaluates progress toward adoption goals. You can also monitor user growth against licensed users and identify trends over time.
9
+
10
+
The Adoption Insights dashboard in {product-short} includes the following cards:
Copy file name to clipboardExpand all lines: assemblies/assembly-configuring-techdocs.adoc
+11-10Lines changed: 11 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
:_mod-docs-content-type: ASSEMBLY
2
2
:context: configuring-techdocs
3
3
[id="{context}"]
4
-
= TechDocs configuration
4
+
= Configuring TechDocs
5
5
6
6
The TechDocs plugin is preinstalled and enabled on a {product-short} instance by default. You can disable or enable the TechDocs plugin, and change other parameters, by configuring the {product} Helm chart or the {product} Operator ConfigMap.
7
7
@@ -19,22 +19,23 @@ After you configure {odf-name} to store the files that TechDocs generates, you c
19
19
20
20
* For more information, see link:{configuring-dynamic-plugins-book-url}[{configuring-dynamic-plugins-book-title}].
Logging is an essential part of monitoring and debugging software applications. It provides insight into how the application is functioning at runtime and can help you detect and diagnose issues. By adjusting the log level, you can control the amount and type of information displayed in the logs, ranging from highly detailed diagnostic output to the most critical errors. With this flexibility, you can customize logging output to match your current requirements, whether during development, testing, or production.
5
+
6
+
You can choose from the following log levels, listed in order of decreasing verbosity:
7
+
8
+
- `debug`: Detailed information, typically useful only when troubleshooting.
9
+
- `info`: General information about the operation of the application. This is the default level.
10
+
- `warn`: Indicates potential issues or situations that might require attention.
11
+
- `error`: Indicates errors that have occurred but might not prevent the application from continuing.
12
+
- `critical`: Indicates critical errors that require immediate attention and are likely to prevent the application from functioning correctly.
13
+
14
+
You can control the verbosity of the logging by setting the log level. The log level determines the minimum severity level of events displayed in the console. For example, if the log level is set to 'info', events with a severity level of 'debug' are ignored.
15
+
16
+
To increase the log level, you can set the `LOG_LEVEL` environment variable to a higher severity level, such as 'warn' or 'error'. However, increasing the log level might not result in more output if the existing code primarily emits logs at lower severity levels, for example, 'debug' or 'info'. In such a case, adjust the logging statements within the code to use higher severity levels to see more output.
17
+
18
+
No additional steps are required beyond setting the `LOG_LEVEL` environment variable, but its effectiveness depends on the existing logging statements in the code.
= Quicklinks and Starred Items in the global header
3
+
4
+
The *Quicklinks* matrix and *Starred Items* drop-down list are enabled by default and appear in the global header without requiring additional configuration.
5
+
6
+
The *Quicklinks* matrix, organized by sections (for example, Documentation or Developer Tools), allows users to quickly access internal or external resources. The *Starred Items* drop-down list contains entities and pages that the user has starred.
7
+
8
+
The default configuration includes the following components:
9
+
10
+
*StarredDropdown*: Displays the *Starred Items* menu in the global header by default, as shown in the following configuration:
*MenuItemLink entries*: Define sections, titles, icons, and links within the *Quicklinks* matrix. The default configuration includes links to the {product-short} documentation and an {product-very-short} Local, as shown in the following configurations:
When upgrading from previous versions, the installer does not overwrite your existing `dynamic-plugins.yaml` configuration. If you had not configured *Starred Items* or *Quicklinks* previously, they remain disabled after the upgrade and must be manually enabled.
= Enabling Quicklinks and Starred Items after an upgrade
3
+
4
+
If you upgrade from {product} `1.6` or earlier, {product} does not automatically enable the *Quicklinks* and *Starred Items* features. You must manually configure these features to display them in the global header.
5
+
6
+
.Prerequisites
7
+
8
+
. You have access to your {product} configuration files.
9
+
. You have administrative permissions to modify ConfigMaps (if using the Operator).
10
+
11
+
.Procedure
12
+
13
+
. Locate your `dynamic-plugin` configuration.
14
+
15
+
* Operator deployment: The configuration is stored in a ConfigMap referenced by your Backstage custom resource (CR).
16
+
* Helm deployment: The configuration is in your `values.yaml` file or separate configuration files.
17
+
18
+
. Enable the global header plugin. Ensure that the `red-hat-developer-hub-backstage-plugin-global-header` entry exists under the `plugins: list` and that `disabled` is set to `false`.
19
+
20
+
. Verify that you enabled the global header plugin.
21
+
Confirm that you listed the `red-hat-developer-hub-backstage-plugin-global-header` plugin under `plugins:` with `disabled: false` (or without a `disabled` property):
0 commit comments