cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana (Observability and Analysis / Observability)
File: use-notification-templates.md

aliases: ../../manage-notifications/template-notifications/use-notification-templates/ # /docs/grafana/<GRAFANA_VERSION>/alerting/manage-notifications/template-notifications/use-notification-templates/ canonical: https://grafana.com/docs/grafana/latest/alerting/configure-notifications/template-notifications/use-notification-templates/ description: Use notification templates in contact points to customize your notifications keywords: grafana alerting notifications templates use templates labels: products: cloud enterprise oss title: Use notification templates weight: 300 Use templates in contact points to customize your notifications. In the Contact points tab, you can see a list of your contact points. To create a new contact point, click New. Note: You can edit an existing contact by clicking the Edit icon. Execute a template from one or more fields such as Message and Subject: {{< figure max-width="940px" src="/static/img/docs/alerting/unified/use-notification-template-9-4.png" caption="Use notification template" >}} For more information on how to write and execute templates, refer to and . Click Save contact point. {{% docs/reference %}} {{% /docs/reference %}}
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: about-ip-address-logging.md

aliases: /docs/phlare/latest/operators-guide/configuring/about-ip-address-logging/ /docs/pyroscope/latest/configure-server/about-ip-address-logging/ description: Troubleshoot errors by logging IP addresses of reverse proxies. menuTitle: About IP address logging of a reverse proxy title: About Grafana Pyroscope IP address logging of a reverse proxy weight: 60 If a reverse proxy is used in front of Pyroscope, it might be difficult to troubleshoot errors. You can use the following settings to log the IP address passed along by the reverse proxy in headers such as `X-Forwarded-For`. `-server.log-source-ips-enabled` Set this to `true` to add IP address logging when a `Forwarded`, `X-Real-IP`, or `X-Forwarded-For` header is used. A field called `sourceIPs` is added to error logs when data is pushed into Grafana Pyroscope. `-server.log-source-ips-header` The header field stores the source IP addresses and is used only if `-server.log-source-ips-enabled` is `true`, and if `-server.log-source-ips-regex` is set. If you do not set these flags, the default `Forwarded`, `X-Real-IP`, or `X-Forwarded-For` headers are searched. `-server.log-source-ips-regex` A regular expression that is used to match the source IPs. The regular expression must contain at least one capturing group, the first of which is returned. This flag is used only if `-server.log-source-ips-enabled` is `true` and if `-server.log-source-ips-header` is set.
Project: Vector (Observability and Analysis / Observability)
File: examples.md

title: VRL example reference short: Examples weight: 3 Here you'll find a comprehensive list of all VRL program examples. These examples demonstrate the breadth of the language and its observability-focused facilities. You can run these examples using the `vector vrl` subcommand with `--input` (input is newline delimited JSON file representing a list of events). and `--program` (VRL program) to pass in the example input and program as well as `--print-object` to show the modified object. The below examples show pretty-printed JSON for the input events, so collapse these to single lines when passing in via `--input`. For example: `vector vrl --input input.json --program program.vrl --print-object`. This closely matches how VRL will receive the input in a running Vector instance. Additionally, if `vector vrl` is run without any arguments, it will spawn a REPL (Readevalprint loop). Assuming you have Vector installed, you can run `vector vrl` to start the REPL. From there, you can type `help` and press return to get further help. The REPL behaves nearly identical to the programs you write for your Vector configuration, and can be used to test individual snippets of complex programs before you commit them to your production configuration. The `vector vrl` command has many other capabilities, run the command using `vector vrl --help` to see more information. {{< vrl/real-world-examples >}} {{< vrl/examples >}}
Project: Grafana Tempo (Observability and Analysis / Observability)
File: TROUBLESHOOTING.md

The most common reason for this issue is improper use of struct tags (eg. `yaml` or `json`). Viper uses under the hood for unmarshaling values which uses `mapstructure` tags by default. Please refer to the library's documentation for using other struct tags. Viper installation seems to fail a lot lately with the following (or a similar) error: ``` cannot find package "github.com/hashicorp/hcl/tree/hcl1" in any of: /usr/local/Cellar/go/1.15.7_1/libexec/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOROOT) /Users/user/go/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOPATH) ``` As the error message suggests, Go tries to look up dependencies in `GOPATH` mode (as it's commonly called) from the `GOPATH`. Viper opted to use to manage its dependencies. While in many cases the two methods are interchangeable, once a dependency releases new (major) versions, `GOPATH` mode is no longer able to decide which version to use, so it'll either use one that's already present or pick a version (usually the `master` branch). The solution is easy: switch to using Go Modules. Please refer to the on how to do that. tl;dr* `export GO111MODULE=on` This is a YAML 1.1 feature according to . Potential solutions are: Quoting values resolved as boolean Upgrading to YAML v3 (for the time being this is possible by passing the `viper_yaml3` tag to your build)
Project: Elastic (Observability and Analysis / Observability)
File: date_diff.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Subtracts the `startTimestamp` from the `endTimestamp` and returns the difference in multiples of `unit`. If `startTimestamp` is later than the `endTimestamp`, negative values are returned. ``` ROW date1 = TODATETIME("2023-12-02T11:00:00.000Z"), date2 = TODATETIME("2023-12-02T11:00:00.001Z") | EVAL ddms = DATEDIFF("microseconds", date1, date2) ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16116.md

key | value | date | 2024-04-05T13:48:37+00:00 version | 2.4.0b1 class | fix edition | cre component | livestatus level | 3 compatible | yes Checkmk 2.3 beta introduced a regression regarding contacts when then Nagios core was used: The association of contacts with hosts, services and contact groups was incorrect. A symptom of this bug were e.g. missing hosts or services in the GUI.
Project: Checkmk (Observability and Analysis / Observability)
File: 16287.md

key | value | date | 2024-01-12T16:30:38+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no Previously, when creating or updating a notification rule, the matchhosttag field would only allow for builtin tag ids. With this werk we now accept any configured host tag id. The schema has also changed in order to make this possible. This means that instead of a field representing each tag, you now have to pass a list of aux tag ids/tag group tag ids along with an operator. This way we can determine if the tag id should match or not. e.g. ``` { "matchhosttags": { "state": "enabled", "value": [ { "tagtype": "auxtag", "tag_id": "snmp", "operator": "is_set", }, { "tagtype": "taggroup", "taggroupid": "criticality", "operator": "is", "tag_id": "prod", }, { "tagtype": "taggroup", "taggroupid": "networking", "operator": "is_not", "tag_id": "lan", } ], }, } ```
Project: Vector (Observability and Analysis / Observability)
File: 2021-10-19-elasticsearch-config-deprecations.md

date: "2021-11-18" title: "Elasticsearch sink config changes and deprecations" description: "" authors: ["fuchsnj"] pr_numbers: [] release: "0.18.0" hideonrelease_notes: false badges: type: "deprecation" Some fields of the elasticsearch sink config are deprecated and scheduled to be removed in 0.19.0 You may view the most recent config options here: https://vector.dev/docs/reference/configuration/sinks/elasticsearch/ | Deprecated Field | New Field | | -- | -- | | `mode = normal` | `mode = bulk` | | `host` | `endpoint` | | `bulk_action` | `bulk.action` | | `index` | `bulk.index` | | `headers` | `request.headers` |
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-the-query-frontend-work-with-prometheus.md

aliases: ../configuring/configuring-the-query-frontend-work-with-prometheus/ configuring-the-query-frontend-work-with-prometheus/ ../operators-guide/configure/configure-the-query-frontend-work-with-prometheus/ description: Learn how to configure the query-frontend to work with Prometheus. menuTitle: Query-frontend to work with Prometheus title: Configure the Grafana Mimir query-frontend to work with Prometheus weight: 90 You can use the Grafana Mimir query-frontend with any Prometheus-API compatible service, including Prometheus and Thanos. Use this configuration file to benefit from query parallelization and caching. <!-- prettier-ignore-start --> ```yml multitenancy_enabled: false target: query-frontend api: prometheushttpprefix: '' server: httplistenport: 9091 frontend: splitqueriesby_interval: 24h alignquerieswith_step: true cache_results: true results_cache: backend: "memcached" memcached: addresses: "dnssrvnoa+memcached.mimir.svc.cluster.local:11211" logquerieslonger_than: 1s downstream_url: http://prometheus.mydomain.com ``` <!-- prettier-ignore-end -->
Project: EaseAgent (Observability and Analysis / Observability)
File: criteria-for-configuring-priorities.md

In EaseAgent, there are the configuration of global variables and the configuration of specified items. When a configuration item has more than two different configurations, we need a simple priority standard to manage it. `This standard should be implemented in EaseAgent, whether it is user-configured or code-configured.` Example: ```yaml plugin.observability.global.metric.topic=application-meter plugin.observability.access.metric.topic=application-log ``` When getting the topic sent by the access metric, what value is obtained? Get the logical AND operation of two values. If there is only one configuration, get its value directly. Example: ```yaml plugin.observability.global.metric.enabled=true plugin.observability.access.metric.enabled=false plugin.observability.global.tracing.enabled=true ``` get access metric enabled -> (true && false) -> false; get httpServlet tracing enabled -> global.tracing.enabled = true Prefer configurations with small coverage. Example: ```yaml plugin.observability.global.metric.topic=application-meter plugin.observability.httpServlet.metric.topic=application-log ``` get httpServlet metric topic -> application-log Why boolean config uses logical AND ? When value is boolean, its meaning is a switch. We want it to be like a light switch: there's a master switch, and then there are switches that control individual bulbs Why we should prioritize configurations with less coverage? When we configure a wide configuration, we mean configure a default value. When we configure a small scope configuration, it means that we need a special value that is different from other configurations. For this reason, we have chosen this criterion. Which configuration is global and which configuration is specific? The definition of global is distinguished by the location of the configuration in the architecture, which needs to be discussed and confirmed by the MegaEase team.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: audit-logs.md

title: Audit Logs Every action taken within the Flagsmith administration application is tracked and logged. This allows you to easily retrace the events and values that flags, identities and segments have taken over time. You can view the Audit Log within the Flagsmith application, and filter it in order to find the information you are after. You can also stream your Audit Logs into your own infrastructure using . Flagsmith records the following events into the Audit Log. New environment created within a Project Environment meta-data updated New Flag created Flag state changed Flag deleted Multivariate flag state changed New Segment created Segment rule updated Segment condition added Segment condition updated Segment overrides re-ordered Identity feature state overridden
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: newrelic.md

title: NewRelic weight: 200 generated_file: true Output plugin send log data to New Relic Logs ```yaml spec: newrelic: license_key: valueFrom: secretKeyRef: name: logging-newrelic key: licenseKey ``` New Relic API Insert key New Relic ingestion endpoint Default: https://log-api.newrelic.com/log/v1 New Relic License Key (recommended) `
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: openobserve.md

title: OpenObserve weight: 200 generated_file: true Send messages to using its . This API accepts multiple records in batch in JSON format. Available in Logging operator version 4.5 and later. {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: SyslogNGOutput metadata: name: openobserve spec: openobserve: url: "https://some-openobserve-endpoint" port: 5080 organization: "default" stream: "default" user: "username" password: valueFrom: secretKeyRef: name: openobserve key: password {{</ highlight >}} For details on the available options of the output, see the . This option enables putting outgoing messages into the disk buffer of the destination to avoid message loss in case of a system failure on the destination side. For details, see the . Default: false Name of the organization in OpenObserve. The port number of the OpenObserve server. Specify it here instead of appending it to the URL. Default: 5080 Arguments to the `$format-json()` template function. Default: `"--scope rfc5424 --exclude DATE --key ISODATE @timestamp=${ISODATE}"` Name of the stream in OpenObserve.
Project: Weave Scope (Observability and Analysis / Observability)
File: faq.md

title: Frequently asked questions menu_order: 95 search_type: Documentation This is answered in [our docs](https://www.weave.works/docs/scope/latest/installing/#k8s). you can choose between two options, either clone the source of Weave Scope, or use the YAML manifests from `cloud.weave.works`. Can be done by using the `probe.no-controls` option and set it to true for the scope agents. This can be done in the scope agents' manifests under the `weave-scope-cluster-agent` deployment and `weave-scope-agent` daemonset argument section with `--probe.no-controls=true`. OSS Scope has no user concept. To limit the access to the UI, setup a reverse proxy with auth and block access to non admin users, capture the calls with something like Chrome network console to get the endpoints to know which requests to authenticate in the proxy server. you can use Basic HTTP Auth since Scope 1.10.0 - just use these command line arguments: ```cli --app.basicAuth Enable basic authentication for app --app.basicAuth.password string Password for basic authentication (default "admin") --app.basicAuth.username string Username for basic authentication (default "admin") --probe.basicAuth Enable basic authentication for app --probe.basicAuth.password string Password for basic authentication (default "admin") --probe.basicAuth.username string Username for basic authentication (default "admin") ``` or alternatively set the environment variables to use the same authentication for Scope app and Scope probe: ```cli ENABLEBASICAUTH: set to "true" BASICAUTHUSERNAME: set to the desired user (default "admin") BASICAUTHPASSWORD: set to the desired password (default "admin") ``` Note that there is no standard programmatic way of expiring a session with Basic Auth, so the users would normally stayed logged in until the authentication params have changed. See for more details. It required patches, @adivyoseph (on ) had done some work on this. says that scope's CI builds ARM32 (but not ARM64) for test-builds at least. @errordeveloper says: It should be easy to add arm64 in CI, You can try and enable builds in ci on a branch.. In theory, you just need to build for `GOARCH=arm64`. Scope doesn't support LDAP right now. OSS Scope reports aren't persistent and the probe keeps the last 15 seconds of metrics in memory. Scope exposes the following http endpoints that can be used for troubleshooting: `/admin/summary` - lists the reports being used by the app, with counts of each node type (containers, processes, etc.). Scope exposes the following endpoints that can be used by external monitoring services. `/api` - Scope status and configuration `/api/probes` - basic status of Scope probes `/api/report` - returns a full JSON report `/api/topology` - information on all topologies `/api/topology/[TOPOLOGY]` - information on all nodes belonging to `TOPOLOGY` topology `/api/topology/ for a proposal of a better solution) You can use `scope launch --app.http.address=127.0.0.1:9000` to run the http server on another port (in this case 9000).
Project: Checkmk (Observability and Analysis / Observability)
File: 16147.md

key | value | date | 2024-01-03T15:27:33+00:00 version | 2.3.0b1 class | fix edition | cee component | cmc level | 1 compatible | yes The errors too many files open (EMFILE) too many files open in system (ENFILE) no buffer space (ENOBUFS) not enough memory (ENOMEM) now exit the core. Correct monitoring cannot be guaranteed when the server is in this state.
Project: Checkmk (Observability and Analysis / Observability)
File: 16365.md

key | value | date | 2024-02-08T08:30:06+00:00 version | 2.4.0b1 class | fix edition | cee component | wato level | 1 compatible | yes Prior to this Werk, the running version of Checkmk was used to display the version of the agents. This caused that after updating Checkmk to a new version, the wrong version of the agents was displayed until they were baked again. To fix this bug, the agent version is now displayed instead of the Checkmk version. SUP-14846
Project: Grafana Tempo (Observability and Analysis / Observability)
File: service-graphs.md

title: Enable service graphs menuTitle: Enable service graphs description: Service graphs help to understand the structure of a distributed system, and the connections and dependencies between its components. weight: aliases: ../../grafana-agent/service-graphs/ # /docs/tempo/<TEMPO_VERSION>/grafana-agent/service-graphs/ A service graph is a visual representation of the interrelationships between various services. Service graphs help to understand the structure of a distributed system, and the connections and dependencies between its components. The same service graph metrics can also be generated by Tempo. This is more efficient and recommended for larger installations. For a deep look into service graphs, visit . Service graphs are also used in the application performance management dashboard. For more information, refer to the . Service graphs are generated in Grafana Agent and pushed to a Prometheus-compatible backend. Once generated, they can be represented in Grafana as a graph. You need these components to fully use service graphs. {{< docs/shared source="alloy" lookup="agent-deprecation.md" version="next" >}} To start using service graphs, enable the feature in Grafana Agent configuration. ```yaml traces: configs: name: default ... service_graphs: enabled: true ``` To see all the available configuration options, refer to the . Metrics are registered in the Agent's default registerer. Therefore, they are exposed at `/metrics` in the Agent's server port (default `12345`). One option is to use the Agent self-scrape capabilities to export the metrics to a Prometheus-compatible backend. ```yaml metrics: configs: name: default scrape_configs: jobname: localscrape static_configs: targets: ['127.0.0.1:12345'] remote_write: url: <remote_write> ``` The same service graph metrics can also be generated by Tempo. This is more efficient and recommended for larger installations. For additional information about viewing service graph metrics in Grafana and calculating cardinality, refer to the .
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.3.md

Upgrade google-oauth-client to 1.33.3 () Upgrade log4j-core to 2.17.1 () Upgrade jdom2 to 2.0.6.1 () Fixing org.opensearch.monitor.os.OsProbeTests::testLogWarnCpuMessageOnlyOnes when CGroups are not available () Fixing org.opensearch.monitor.os.OsProbeTests > testLogWarnCpuMessageOnlyOnes when cgroups are available but cgroup stats is not ()
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-0-1.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.0.1 <!-- Auto generated by update changelog github action --> Alerting/SSE: Fix "countnonnull" reducer validation. , Cloudwatch: Fix duplicated time series. , Cloudwatch: Fix missing defaultRegion. , Dashboard: Fix Dashboard init failed error on dashboards with old singlestat panels in collapsed rows. , Datasource: Fix storing timeout option as numeric. , Postgres/MySQL/MSSQL: Fix annotation parsing for empty responses. , Postgres/MySQL/MSSQL: Numeric/non-string values are now returned from query variables. , Postgres: Fix an error that was thrown when the annotation query did not return any results. , StatPanel: Fix an issue with the appearance of the graph when switching color mode. , Visualizations: Fix an issue in the Stat/BarGauge/Gauge/PieChart panels where all values mode were showing the same name if they had the same value.. , Toolkit: Resolve external fonts when Grafana is served from a sub path. ,
Project: Elastic (Observability and Analysis / Observability)
File: left.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns the substring that extracts 'length' chars from 'string' starting from the left. ``` FROM employees | KEEP last_name | EVAL left = LEFT(last_name, 3) | SORT last_name ASC | LIMIT 5 ```
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: fluentbit-config-reload.md

It is now possible to configure Fluent Bit to reload its configuration on the fly. This behaviour is disabled by default, but can be enabled with a single configuration option under the Logging's `spec.fluentbit.configHotReload` (legacy method) or the new FluentbitAgent's `spec.configHotReload`: ``` apiVersion: logging.banzaicloud.io/v1beta1 kind: FluentbitAgent metadata: name: reload-example spec: configHotReload: {} ``` Currently `resources` and `image` is configurable: ``` apiVersion: logging.banzaicloud.io/v1beta1 kind: FluentbitAgent metadata: name: reload-example spec: configHotReload: resources: ... image: repository: ghcr.io/kube-logging/config-reloader tag: v0.0.5 ``` For all the available configuration options please check the
Project: Graylog (Observability and Analysis / Observability)
File: NavDropdown.md

```js import { Nav, NavDropdown, MenuItem } from 'components/bootstrap'; <Nav activeKey="1.1"> <NavDropdown eventKey="1" title="Dropdown" id="nav-dropdown"> <MenuItem eventKey="1.1">Action</MenuItem> <MenuItem eventKey="1.2">Another action</MenuItem> <MenuItem eventKey="1.3">Something else here</MenuItem> <MenuItem divider /> <MenuItem eventKey="1.4">Separated link</MenuItem> </NavDropdown> </Nav> ```