cwielenb/CNCF-Dataset huggingface dataset:
Project: Netdata (Observability and Analysis / Observability)
File: megacli_pd_media_errors.md

The `megaclipdmedia_errors` alert is triggered when there are media errors on the physical disks attached to the MegaCLI controller. A media error is an event where a storage disk was unable to perform the requested I/O operation due to problems accessing the stored data. This alert indicates that a bad sector was found on the drive during a patrol check or from a rebuild operation on a specific disk by the RAID adapter. Although this does not mean imminent disk failure, it is a warning, and you should monitor the affected disk. Data is priceless. Before you perform any action, make sure that you have taken any necessary backup steps. Netdata is not liable for any loss or corruption of any data, database, or software. Gather more information about your virtual drives on all adapters: ``` megacli LDInfo -Lall -aALL ``` Check which virtual drive is reporting media errors and in which adapter. Check the Bad block table for the virtual drive in question: ``` megacli GetBbtEntries -LX -aY // X: virtual drive, Y: the adapter ``` Consult the MegaRAID SAS Software User Guide's section 7.17.11[^1] to recheck these block entries. This operation removes any data stored on the physical drives. Back up the good data on the drives before making any changes to the configuration.
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: vmrule.md

sort: 10 weight: 10 title: VMRule menu: docs: parent: "operator-custom-resources" weight: 10 aliases: /operator/resources/vmrule.html `VMRule` represents or rules for instances. The `VMRule` CRD declaratively defines a desired Prometheus rule to be consumed by one or more VMAlert instances. `VMRule` object generates with ruleset defined at `VMRule` spec. Alerts and recording rules can be saved and applied as YAML files, and dynamically loaded without requiring any restart. See more details about rule configuration in . You can see the full actual specification of the `VMRule` resource in the . Also, you can check out the section. Custom resource `VMRule` supports feature from . For using in `VMRule` you need to . After that you can add `tenant` field for groups in `VMRule`: ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMRule metadata: name: vmrule-ent-example spec: groups: name: vmalert-1 rules: tenant: 1 alert: vmalert config reload error expr: delta(vmalertconfiglastreloaderrors_total[5m]) > 0 for: 10s labels: severity: major job: "{{ $labels.job }}" annotations: value: "{{ $value }}" description: 'error reloading vmalert config, reload count for 5 min {{ $value }}' ``` ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMRule metadata: name: vmrule-alerting-example spec: groups: name: vmalert rules: alert: vmalert config reload error expr: delta(vmalertconfiglastreloaderrors_total[5m]) > 0 for: 10s labels: severity: major job: "{{ $labels.job }}" annotations: value: "{{ $value }}" description: 'error reloading vmalert config, reload count for 5 min {{ $value }}' ``` ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMRule metadata: name: vmrule-recording-example spec: groups: name: vmrulerecordinggroupname interval: 1m rules: record: vmhttprequesterrorstotal:sumbyclusternamespacejob:rate:5m expr: |- sum by (cluster, namespace, job) ( rate(vmhttprequesterrorstotal[5m]) ) ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16389.md

key | value | date | 2024-01-26T15:59:51+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes Previously, failed login attempts with an unknown user would create a user profile directory. This is no longer the case. The profile directory is now only created for valid users.
Project: Netdata (Observability and Analysis / Observability)
File: postgres_index_bloat_size_perc.md

This alert monitors index bloat in a PostgreSQL database table. If you receive this alert, it indicates that the index is bloated and is taking up more disk space than necessary, which can lead to performance issues. In PostgreSQL, when a row is updated or deleted, the old row data remains in the index while the new data is added. Over time, this causes the index to grow in size (bloat), leading to increased disk usage and degraded query performance. This alert measures the bloat size percentage for each index in the specified database and table. Identify the bloated index in your PostgreSQL database, as mentioned in the alert's info field (e.g. `db [database] table [table] index [index]`). Rebuild the bloated index: Use the `REINDEX` command to rebuild the bloated index. This will free up the space occupied by the old row data and help optimize query performance. ``` REINDEX INDEX [index_name]; ``` Note: `REINDEX` might lock the table for the time it takes to rebuild the index, so plan to run this command during maintenance periods or during low database usage periods. Monitor the index bloat size after rebuilding: After rebuilding the index, continue monitoring the index bloat size and performance to ensure the issue has been resolved. You can use tools like (a built-in PostgreSQL extension) and pgstatindexes (user-defined database views that collect index-related statistics) to keep an eye on your database's performance and catch any bloat issues before they negatively impact your PostgreSQL setup.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-0-6.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.0.6 <!-- Auto generated by update changelog github action --> Access Control: Allow org admins to invite new users to their organization. , Grafana/toolkit: Fix incorrect image and font generation for plugin builds. , Prometheus: Fix adding of multiple values for regex operator. , UI/Card: Fix card items always having pointer cursor. ,
Project: InfluxData (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Opening a feature request kicks off a discussion <!-- Thank you for suggesting an idea to improve InfluxDB IOx. Have you read the contributing section of the README? Please do if you haven't. https://github.com/influxdata/influxdb/blob/main/README.md Please ask usage questions in the Influx Slack (there is an #influxdb-iox channel). https://influxdata.com/slack If the feature you're interested in already has an open or* closed ticket associated with it (please search) please don't add "+1" or "me too" comments. The Github reaction emojis are a way to indicate your support for something and will contribute to prioritisation. --> Use case: Why is this important (helps with prioritizing requests)? Proposal: Short summary of the feature. Current behaviour: Describe what currently happens. Desired behaviour: Describe what you want. Alternatives considered: Describe other solutions or features you considered.
Project: Netdata (Observability and Analysis / Observability)
File: _concept-page-template.md

<!-- title: Noun that describes the concept description:Short summary (will be displayed in search engines) customediturl:Edit URL of the source file keywords: [keywords, describing, the main topics] --> Why should the reader care: Whats in it for me? Ideally, try to explain one core idea per section. Questions that you could keep in mind while writing: How does it work? What are the outcomes? What are the positive and negative effects of it? Are there alternatives that provide a similar result? Add more subheadings and anything else that needs to be explained... Remember, if you start to describe about another concept, stop yourself. Each concept should be about one concept only. <!-- Optional --> <!-- Here, you could include links to task topic that describe how to implement the thing you discussed in this concept. --> Visit the to learn more about related thing.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: faq.md

sidebar_position: 100 This one of most common question I get. Feature flags are a software development technique that turns certain functionality on and off during runtime, without deploying new code. It allows you to decouple deploy and release, giving you better control and more experimentation over the full lifecycle of features. The lifecycle of your flags is key if you don't want to have un-used things everywhere in your code. Start by creating the flag in your configuration file (with 0% to avoid affecting your users). Evaluate the flag in your code (see ). Deploy your application with the variation check. Start rolling out your flag. When 100% of your users have access to the new feature, remove the call to the variation from your code base. Deploy your application without the variation check. Remove the flag from your configuration file. If while you are on production for some reason your flag file becomes unreachable, we will be able to serve the users based on the last version of the file we were able to read. We will continue to try reading the file based on the `pollingInterval` you have configured. If you start a new instance, if the file is not reachable to module will fail to initialize except if you have set the option `StartWithRetrieverError` in the config. With this option, we will serve the SDK default value *(the 3rd param in your variation)* until the flag becomes available again. The lib gives you a lot of strategies to rollout your flags, there is no better one, it always depends on the context of your release. If your release is not critical and, you just want an easy cut-off strategy, you can pass your flag from 0% to 100% for all your users If you are scared that your infrastructure can be impacted by the new feature, a progressive rollout can help you to impact users over time and to be able to check how your system handle it. If you want to impact only a subset of your users, you can put a rule on your flag. Etc ... You have an endless list of rollout strategies depending on what is your feature. To avoid always have the same users affected by a flag, the hash we compute that allows us to determine if the user is part of the percentage is not computed only based on the user key but a combination of the user key and the flag name. It guarantees that the user will be always in the same group but depending on the flag.
Project: Jaeger (Observability and Analysis / Observability)
File: MAINTAINERS.md

The current Maintainers Group for the Jaeger Project consists of: | Name | Employer | Responsibilities | | - | -- | - | | | PackSmith | ALL | | | Aiven | ALL | | | Grafana Labs | ALL | | | RedHat | ALL | | | Meta | ALL | This list must be kept in sync with the . See for how maintainers are selected and replaced.
Project: Grafana Loki (Observability and Analysis / Observability)
File: regex.md

title: regex menuTitle: description: The 'regex' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/regex/ weight: The `regex` stage is a parsing stage that parses a log line using a regular expression. Named capture groups in the regex support adding data into the extracted map. ```yaml regex: expression: <string> [source: <string>] ``` `expression` needs to be a [Go RE2 regex string](https://github.com/google/re2/wiki/Syntax). Every capture group `(re)` will be set into the `extracted` map, every capture group must be named: `(?P<name>re)`. The name of the capture group will be used as the key in the extracted map. Because of how YAML treats backslashes in double-quoted strings, note that all backslashes in a regex expression must be escaped when using double quotes. For example, all of these are valid: `expression: \w*` `expression: '\w*'` `expression: "\\w*"` But these are not: `expression: \\w*` (only escape backslashes when using double quotes) `expression: '\\w*'` (only escape backslashes when using double quotes) `expression: "\w*"` (backslash must be escaped) If you run Promtail with the `--config.expand-env=true` flag the configuration will run through which will replace double backslashes with single backslashes. Because of this when using `expand-env=true` you need to use double backslashes for each single backslash. For example: `expression: '\w'` must be `expression: '\\w'` `expression: "\\w"` must be `expression: "\\\\w"` Given the pipeline: ```yaml regex: expression: "^(?s)(?P<time>\\S+?) (?P<stream>stdout|stderr) (?P<flags>\\S+?) (?P<content>.*)$" ``` And the log line: ``` 2019-01-01T01:00:00.000000001Z stderr P i'm a log message! ``` The following key-value pairs would be added to the extracted map: `time`: `2019-01-01T01:00:00.000000001Z`, `stream`: `stderr`, `flags`: `P`, `content`: `i'm a log message` Given the pipeline: ```yaml json: expressions: time: regex: expression: "^(?P<year>\\d+)" source: "time" ``` And the log line: ``` {"time":"2019-01-01T01:00:00.000000001Z"} ``` The first stage would add the following key-value pairs into the `extracted` map: `time`: `2019-01-01T01:00:00.000000001Z` While the regex stage would then parse the value for `time` in the extracted map and append the following key-value pairs back into the extracted map: `year`: `2019`
Project: Graylog (Observability and Analysis / Observability)
File: Select.md

Simple option input: ```js import createReactClass from 'create-react-class'; const SimpleSelect = createReactClass({ getInitialState() { return { options: [ { label: 'Option 1', value: 'one' }, { label: 'Option 2', value: 'two' }, ], selectedOption: '', }; }, onChange(nextValue) { this.setState({selectedOption: nextValue}); }, render() { const { options, selectedOption } = this.state; return ( <div> <span>Selected option: "{selectedOption}"</span> <Select value={selectedOption} onChange={this.onChange} options={options}/> </div> ); }, }); <SimpleSelect /> ``` Multi select input: ```js import createReactClass from 'create-react-class'; import { MultiSelect } from 'components/common'; const SimpleSelect = createReactClass({ getInitialState() { return { options: [ { spanish: 'uno', english: 'one' }, { spanish: 'dos', english: 'two' }, { spanish: 'tres', english: 'three' }, { spanish: 'cuatro', english: 'four' }, { spanish: 'cinco', english: 'five' }, ], selectedOptions: 'one;three;five', }; }, onChange(nextValue) { this.setState({selectedOptions: nextValue}); }, render() { const { options, selectedOptions } = this.state; return ( <div> <span>Selected options: "{selectedOptions}"</span> <MultiSelect value={selectedOptions} onChange={this.onChange} options={options} displayKey="spanish" valueKey="english" delimiter=";" allowCreate /> </div> ); }, }); <SimpleSelect /> ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: migrationguide.md

This guide is intended to assist in the migration from the `azure-storage-blob-go` module, or previous betas of `azblob`, to the latest releases of the `azblob` module. The redesign of the `azblob` module separates clients into various sub-packages. In previous versions, the public surface area was "flat", so all clients and supporting types were in the `azblob` package. This made it difficult to navigate the public surface area. In `azure-storage-blob-go` a client constructor always requires a `url.URL` and `Pipeline` parameters. In `azblob` a client constructor always requires a `string` URL, any specified credential type, and a `*ClientOptions` for optional values. You pass `nil` to accept default options. ```go // new code client, err := azblob.NewClient("<my storage account URL>", cred, nil) ``` In `azure-storage-blob-go` you created a `Pipeline` with the required credential type. This pipeline was then passed to the client constructor. In `azblob`, you pass the required credential directly to the client constructor. ```go // new code. cred is an AAD token credential created from the azidentity module client, err := azblob.NewClient("<my storage account URL>", cred, nil) ``` The `azure-storage-blob-go` module provided limited support for OAuth token authentication via `NewTokenCredential`. This been replaced by using Azure Identity credentials from . Authentication with a shared key via `NewSharedKeyCredential` remains unchanged. In `azure-storage-blob-go` you created a `Pipeline` with `NewAnonymousCredential` to support anonymous or SAS authentication. In `azblob` you use the construtor `NewClientWithNoCredential()` instead. ```go // new code client, err := azblob.NewClientWithNoCredential("<public blob or blob with SAS URL>", nil) ``` In `azure-storage-blob-go` you explicitly created a `Marker` type that was used to page over results (). In `azblob`, operations that return paginated values return a `*runtime.Pager[T]`. ```go // new code pager := client.NewListBlobsFlatPager("my-container", nil) for pager.More() { page, err := pager.NextPage(context.TODO()) // process results } ``` In `azure-storage-blob-go` you explicitly created a HTTP pipeline with configuration before creating a client. This pipeline instance was then passed as an argument to the client constructor (). In `azblob` a HTTP pipeline is created during client construction. The pipeline is configured through the `azcore.ClientOptions` type. ```go // new code client, err := azblob.NewClient(account, cred, &azblob.ClientOptions{ ClientOptions: azcore.ClientOptions{ // configure HTTP pipeline options here }, }) ```
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-1-7.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.1.7 <!-- Auto generated by update changelog github action --> Chore: Upgrade Go version to 1.19.1 (backport). , CloudWatch: Add missing AWS/Prometheus metrics. , Explore: Add feature tracking events. , Graphite: Add error information to graphite queries tracing. , Prometheus: Restore FromAlert header. , SAML: Account for all orgs in org_mapping (#3855). (Enterprise) Search: Add search index configuration options. , Thresholds: Add option for dashed line style. , Alerting: Fix default query's data source when no default datasource specified. , Alerting: Fix mathexp.NoData cannot be reduced. , Alerting: Skip unsupported file types on provisioning. , AzureMonitor: Ensure resourceURI template variable is migrated. , Dashboard: Fix plugin dashboard save as button. , Docs: Fix decimals: auto docs for panel edit. , Fix: RBAC handle `error no resolver` found. , Fix: RBAC handle `error no resolver` found. (Enterprise) LibraryPanelSearch: Refactor and fix hyphen issue. , Live: Fix live streaming with `live-service-web-worker` feature flag enabled. , QueryField: Fix wrong cursor position on autocomplete. ,
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_run.md

Run tests and test suites Run tests and test suites ``` tracetest run [test|testsuite] [flags] ``` ``` -f, --file strings path to the definition file (can be defined multiple times) -g, --group string Sets the Run Group ID for the run. This is used to group multiple runs together. -h, --help help for run --id strings id of the resource to run (can be defined multiple times) -j, --junit string file path to save test results in junit format --required-gates strings override default required gate. valid options: analyzer-score, analyzer-rules, test-specs -W, --skip-result-wait do not wait for results. exit immediately after test run started --vars string variable set file or ID to be used ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - CLI to configure, install and execute tests on a Tracetest server
Project: SkyWalking (Observability and Analysis / Observability)
File: dynamic-config-service.md

is a gRPC service which requires implementation of the upstream system. The SkyWalking OAP fetches the configuration from the implementation (any system) after you open the implementation like this: ```yaml configuration: selector: ${SW_CONFIGURATION:grpc} grpc: host: ${SWDCSSERVER_HOST:""} port: ${SWDCSSERVER_PORT:80} clusterName: ${SWDCSCLUSTER_NAME:SkyWalking} period: ${SWDCSPERIOD:20} ``` `uuid`: To identify whether the config data changed, if `uuid` is the same, it is not required to respond to the config data. Implement: ``` rpc call (ConfigurationRequest) returns (ConfigurationResponse) { } ``` e.g. The config is: ``` {agent-analyzer.default.slowDBAccessThreshold}:{default:200,mongodb:50} ``` The response `configTable` is: ``` configTable { name: "agent-analyzer.default.slowDBAccessThreshold" value: "default:200,mongodb:50" } ``` Implement: ``` rpc callGroup (ConfigurationRequest) returns (GroupConfigurationResponse) {} ``` Respond config data `GroupConfigItems groupConfigTable` e.g. The config is: ``` {core.default.endpoint-name-grouping-openapi}:|{customerAPI-v1}:{value of customerAPI-v1} |{productAPI-v1}:{value of productAPI-v1} |{productAPI-v2}:{value of productAPI-v2} ``` The response `groupConfigTable` is: ``` groupConfigTable { groupName: "core.default.endpoint-name-grouping-openapi" items { name: "customerAPI-v1" value: "value of customerAPI-v1" } items { name: "productAPI-v1" value: "value of productAPI-v1" } items { name: "productAPI-v2" value: "value of productAPI-v2" } } ```