cwielenb/CNCF-Dataset huggingface dataset:
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-meter.md

The meter receiver accepts the metrics of into the . Module definition is defined in `application.yml`, typically located at `$SKYWALKINGBASEDIR/config/application.yml` by default. ```yaml receiver-meter: selector: ${SWRECEIVERMETER:default} default: ``` In Kafka Fetcher, follow these configurations to enable it. ```yaml kafka-fetcher: selector: ${SWKAFKAFETCHER:default} default: bootstrapServers: ${SWKAFKAFETCHER_SERVERS:localhost:9092} ``` Custom metrics may be collected by the Manual Meter API. Custom metrics collected cannot be used directly; they should be configured in the `meter-analyzer-config` configuration files described in the next part. The receiver adds labels with `key = service` and `key = instance` to the collected data samples, and values from service and service instance name defined in SkyWalking Agent, for identification of the metric data. There are following known API libs to report meter telemetry data: works with All following agents and components have built-in meters reporting to the OAP through Meter APIs. Go agent for Go VM metrics Python agent for PVM metrics Java agent with Spring micrometer toolkit Java agent for datasource metrics Java agent for thread-pool metrics Rover(eBPF) agent for metrics used continues profiling Satellite proxy self-observability metrics The meter receiver is configured via a configuration file. The configuration file defines everything related to receiving from agents, as well as which rule files to load. The OAP can load the configuration at bootstrap. If the new configuration is not well-formed, the OAP may fail to start up. The files are located at `$CLASSPATH/meter-analyzer-config`. New meter-analyzer-config files is NOT enabled by default, you should make meter configuration take effect through section `agent-analyzer` in `application.yml` of skywalking backend. ```yaml agent-analyzer: selector: ${SWAGENTANALYZER:default} default: meterAnalyzerActiveFiles: ${SWMETERANALYZERACTIVEFILES:your-custom-meter-conf-without-ext-name} # The multiple files should be separated by "," ``` Meter-analyzer-config file is written in YAML format, defined by the scheme described below. Brackets indicate that a parameter is optional. ```yaml initExp: <string> filter: <closure> # example: '{ tags -> tags.job_name == "vm-monitoring" }' expPrefix: <string> expSuffix: <string> metricPrefix: <string> metricsRules: name: <string> exp: <string> ``` For more information on MAL, please refer to Although we support the `rate`, `irate`, `increase` functions in the backend, we still recommend users to consider using client-side APIs to run these functions. The reasons are as follows: The OAP has to set up caches to calculate the values. Once the agent reconnects to another OAP instance, the time windows of rate calculation break. This leads to inaccurate results.
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-28-custom-vector-builds.md

date: "2020-04-16" title: " la carte Custom Vector Builds" description: "Build Vector with select components" authors: ["binarylogic"] pr_numbers: [1924] release: "0.9.0" hideonrelease_notes: false badges: type: "new feature" domains: ["sources"] sources: ["vector"] We've implemented a feature flag system that lets you build custom versions of Vector with selected . This is handy if: You're embedding Vector and you want to minimize the binary size as much as possible. You're security requires are extremely sensitive and you want to reduce the footprint of features that Vector exposes. To get started, check out the section in our . For example: ```bash FEATURES="sources-file,transforms-json_parser,sinks-kafka" make build ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16658.md

key | value | date | 2024-04-09T12:01:49+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | yes This werk adds the `mode` query parameter to the delete endpoint for host tag groups. It is an alternative to the existing `repair` parameter, with the following options: `mode=abort` default behaviour, cancel deletion if tag group is in use `mode=delete` same as `repair=True`, will delete affected rules `mode=remove` will remove the tag group condition from rules instead of deleting the entire rule
Project: Grafana (Observability and Analysis / Observability)
File: auth.md

aliases: ../../http_api/auth/ ../../http_api/authentication/ canonical: /docs/grafana/latest/developers/http_api/auth/ description: Grafana Authentication HTTP API keywords: grafana http documentation api authentication labels: products: enterprise oss title: 'Authentication HTTP API ' The Authentication HTTP API is used to manage API keys. {{% admonition type="note" %}} If you use Grafana v9.1 or newer, use service accounts instead of API keys. For more information, refer to . {{% /admonition %}} If you are running Grafana Enterprise, for some endpoints you would need to have relevant permissions. Refer to for more information. `GET /api/auth/keys` Required permissions See note in the for an explanation. | Action | Scope | | -- | -- | | `apikeys:read` | `apikeys:*` | Example Request: ```http GET /api/auth/keys HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk ``` Query Parameters: `includeExpired`: boolean. enable listing of expired keys. Optional. Example Response: ```http HTTP/1.1 200 Content-Type: application/json [ { "id": 3, "name": "API", "role": "Admin" }, { "id": 1, "name": "TestAdmin", "role": "Admin", "expiration": "2019-06-26T10:52:03+03:00" } ] ``` `POST /api/auth/keys` Required permissions See note in the for an explanation. | Action | Scope | | - | -- | | `apikeys:create` | n/a | Example Request: ```http POST /api/auth/keys HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk { "name": "mykey", "role": "Admin", "secondsToLive": 86400 } ``` JSON Body schema: name The key name role Sets the access level/Grafana Role for the key. Can be one of the following values: `Viewer`, `Editor` or `Admin`. secondsToLive Sets the key expiration in seconds. It is optional. If it is a positive number an expiration date for the key is set. If it is null, zero or is omitted completely (unless `apikeymaxsecondsto_live` configuration option is set) the key will never expire. Error statuses: 400 `apikeymaxsecondsto_live` is set but no `secondsToLive` is specified or `secondsToLive` is greater than this value. 500 The key was unable to be stored in the database. Example Response: ```http HTTP/1.1 200 Content-Type: application/json {"name":"mykey","key":"eyJrIjoiWHZiSWd3NzdCYUZnNUtibE9obUpESmE3bzJYNDRIc0UiLCJuIjoibXlrZXkiLCJpZCI6MX1=","id":1} ``` `DELETE /api/auth/keys/:id` Required permissions See note in the for an explanation. | Action | Scope | | - | - | | `apikeys:delete` | apikeys:\* | Example Request: ```http DELETE /api/auth/keys/3 HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk ``` Example Response: ```http HTTP/1.1 200 Content-Type: application/json {"message":"API key deleted"} ```
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.AppLogoProps.md

title: "Interface: AppLogoProps" linkTitle: "AppLogoProps" slug: "plugin_registry.AppLogoProps" .AppLogoProps `Optional` className: `string` A class to use on your SVG. _ `Optional` logoType: ``"small"`` \| ``"large"`` The size of the logo. 'small' for in mobile view, and 'large' for tablet and desktop sizes. By default the 'large' is used. _ `Optional` sx: `SxProps`<`Theme`\> SxProps to use on your SVG. _ `Optional` themeName: ``"dark"`` \| ``"light"`` User selected theme. By default it checks which is is active.
Project: M3 (Observability and Analysis / Observability)
File: m3aggregator_intro.md

M3 Aggregator is a dedicated metrics aggregator that provides stateful stream-based downsampling before storing metrics in M3DB nodes. It uses dynamic rules stored in etcd . It uses leader election and aggregation window tracking, leveraging etcd to manage this state, to reliably emit at-least-once aggregations for downsampled metrics to long term storage. This provides cost effective and reliable downsampling & roll up of metrics. M3 Coordinator can also perform this role, but M3 Aggregator shards and replicates metrics, whereas M3 Coordinator is not and requires care to deploy and run in a highly available way. Similar to M3DB, M3 Aggregator supports clustering and replication by default. This means that metrics are correctly routed to the instance(s) responsible for aggregating each metric and you can configure multiple M3 Aggregator replicas so that there are no single points of failure for aggregation. {{% notice warning %}} M3 Aggregator is in heavy development to make it more usable without requiring you to write your own compatible producer and consumer. {{% /notice %}}
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v3.3.md

title: "Grafana Mimir Helm chart version 3.3 release notes" menuTitle: "V3.3 release notes" description: "Release notes for Grafana Mimir Helm chart version 3.3" weight: 300 Grafana Labs is excited to announce version 3.3 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.4 or Grafana Enterprise Metrics (GEM) v2.4. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. To learn about new features and enhancements in Grafana Mimir or GEM, see the release notes for or . The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . This is a re-release of Grafana Mimir Helm chart version 3.2 to include GEM version v2.4.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: geoip.md

title: Geo IP weight: 200 generated_file: true Fluentd Filter plugin to add information about geographical location of IP addresses with Maxmind GeoIP databases. More information at https://github.com/y-ken/fluent-plugin-geoip Specify backend library (geoip2c, geoip, geoip2compat) Specify optional geoip2 database (using bundled GeoLite2-City.mmdb by default) Specify optional geoip database (using bundled GeoLiteCity databse by default) Specify one or more geoip lookup field which has ip address Default: host Records are represented as maps: `key: value` To avoid get stacktrace error with `[null, null]` array for elasticsearch. Default: true {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: geoip: geoiplookupkeys: remote_addr records: city: ${city.names.en["remote_addr"]} location_array: '''[${location.longitude["remote"]},${location.latitude["remote"]}]''' country: ${country.isocode["remoteaddr"]} countryname: ${country.names.en["remoteaddr"]} postalcode: ${postal.code["remoteaddr"]} selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type geoip @id test_geoip geoiplookupkeys remote_addr skipaddingnull_record true <record> city ${city.names.en["remote_addr"]} country ${country.isocode["remoteaddr"]} countryname ${country.names.en["remoteaddr"]} location_array '[${location.longitude["remote"]},${location.latitude["remote"]}]' postalcode ${postal.code["remoteaddr"]} </record> </filter> {{</ highlight >}}
Project: Netdata (Observability and Analysis / Observability)
File: mysql_10s_table_locks_immediate.md

This alert is triggered when the number of table immediate locks in MySQL increases within the last 10 seconds. Table locks are used to control concurrent access to tables, and immediate locks are granted when the requested lock is available. In MySQL, table immediate locks are a mechanism for managing concurrent access to tables. When a table lock is requested and is available, an immediate lock is granted, allowing the process to continue execution. This ensures that multiple processes can't modify the data simultaneously, which could cause data inconsistencies. Identify the queries causing the table locks: You can use the following command to display the process list in MySQL, which will include information about the locks: ``` SHOW FULL PROCESSLIST; ``` Analyze the queries: Check the queries causing the table locks to determine if they are necessary, can be optimized, or should be terminated. To terminate a specific query, use the `KILL QUERY` command followed by the connection ID: ``` KILL QUERY connection_id; ``` Check table lock status: To get more information about the lock status, you can use the following command to display the lock status of all tables: ``` SHOW OPEN TABLES WHERE in_use > 0; ``` Optimize database queries and configurations: Improve query performance by optimizing the queries and indexing the tables. Additionally, check your MySQL configuration and adjust it if necessary to minimize the number of locks required. Monitor the lock situation: Keep monitoring the lock situation with the `SHOW FULL PROCESSLIST` command to see if the problem persists. If the issue is not resolved, consider increasing the MySQL lock timeout or seek assistance from a database administrator or the MySQL community.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: 20220706-universal-resource-optimization.md

Universal Resource Optimization provide a consistence progress to optimize variable kinds of resources in kubernetes. The progress should be Pluggable and support Multi-Cloud. <!-- TOC --> <!-- /TOC --> Currently, we use `Analytics` and `Recommendation` to provide a recommendation service for workloads in cluster. Kubernetes' users use the recommendation to optimize the resource configuration and reduce their cost. But the recommendations have some limitations now: Multiple Analytics can select some same resources, it's confused and unnecessary to have two recommendation for the same resource. We need to support more kinds of resources, for example, scan for idle load balancers. We need to make the progress Pluggable to support different user in difference clouds. Global analytics rules Easy to know the recommendation for my resource Consistence progress for all resource recommendation Plugin mechanism to support Multi-Cloud Cloud Resources that not included in kubernetes Recommendation Definition Recommendation Framework As a Serverless customer, I want to know the suitable requests and limits for my deployments, the result should be fit the existing pod model(e.g. 2c4g, 1c1g) in my cloud production. As an Aliyun ACK customer, I want to know whether there is a waste of LoadBalances in my cluster and delete them if exists. As a container platform user, I want to integrate optimize recommendation to my platform and optimize my cluster within my CICD pipeline.
Project: Vector (Observability and Analysis / Observability)
File: 2021-12-15-splunk-hec-improvements.md

date: "2021-12-15" title: "Splunk HEC Improvements" description: "Improved compatibility with Splunk HTTP Event Collector" authors: ["barieom"] pr_numbers: [10261, 10135] release: "0.19.0" hideonrelease_notes: false badges: type: enhancement We're excited to share that we've made a few improvements to Vector's support for ; Vector now supports Splunk HEC indexer acknowledgements and channel token passthrough routing. With the new support for Splunk HEC indexer acknowledgement, Vector is now able to provide higher guarantees that no data is lost when using the `splunk_hec` source and sink. As you may be aware, Splunk HEC does not guarantee that data is successfully written when it responds to an incoming request successfully. To confirm that data has been persisted, the feature must be enabled. The status of sent events can then be queried via a separate endpoint. Previously, the `splunk_hec` source did not support [indexer acknowledgements][indexer] and so would provide weaker delivery guarantees and would not work with Splunk senders that required them. Now, you can configure the `splunk_hec` source to use the indexer acknowledgements protocol by configuring: ```toml acknowledgements = true ``` When enabled, responses to incoming requests will include an ID that can be used to query for acknowledgement status at the newly exposed `/services/collector/ack` endpoint (). The acknowledgement status is wired into Vector's forthcoming end-to-end acknowledgement feature. This feature will require that events be sent by sinks or persisted into disk buffers before sources will acknowledge them. Previously, the `splunk_hec` sink simply treated successful HEC requests as the events being acknowledged by the Spunk receiver and so Vector would drop them from any buffers. Now, it is possible to configure the sink to wait until the Splunk receiver acknowledges the events via the [index acknowledgements][indexer] part of the HEC protocol. This has defaulted to on to provide higher guarantees, but can be disabled to restore the previous behavior by configuring: ```toml acknowledgements.indexeracknowledgementsenabled = false ``` Vector now also supports Splunk HEC token passthrough routing. When `storehectoken` is enabled in a `splunk_hec` source, tokens included in requests to the source will be stored and used by downstream `splunk_hec` sinks. Any passed through token takes precedence over the `default_token` configuration set in the sink. We hope that these improvements can make your experience using Vector with Splunk better! If you any feedback for us, let us know on our [Discord chat] or on [Twitter].
Project: Cortex (Observability and Analysis / Observability)
File: how-to-add-a-maintainer.md

title: "How to add a maintainer" linkTitle: "How to add a maintainer" weight: 10 slug: how-to-add-a-maintainer New maintainers are proposed by an existing maintainer and are elected by . Once the vote passed, the following steps should be done to add a new member to the maintainers team: Submit a PR to add the new member to `MAINTAINERS` Invite to Invite to Invite to Invite to Submit a PR to Invite to (via ) Invite to Invite to Add to the Google Analytics property used for the website statistics Invite to credentials vault
Project: Sidekick (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Please complete the following information OS: [e.g. MacOS] Arch: [e.g. x64, Apple Silicon] Client [e.g. VSCode, IntelliJ IDEA] Runtime: [e.g. node.js, Java] Additional context Add any other context about the problem here.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: kinesis_stream.md

title: Amazon Kinesis weight: 200 generated_file: true For details, see . ```yaml spec: kinesisStream: stream_name: example-stream-name region: us-east-1 format: type: json ``` Send your logs to a Kinesis Stream The number of attempts to make (with exponential backoff) when loading instance profile credentials from the EC2 metadata service using an IAM role. Defaults to 5 retries. AWS access key id. This parameter is required when your agent is not running on EC2 instance with an IAM Role. AWS secret key. This parameter is required when your agent is not running on EC2 instance with an IAM Role. AWS session token. This parameter is optional, but can be provided if using MFA or temporary credentials when your agent is not running on EC2 instance with an IAM Role. Typically, you can use AssumeRole for cross-account access or federation. Integer, default 500. The number of max count of making batch request from record chunk. It can't exceed the default value because it's API limit. Integer. The number of max size of making batch request from record chunk. It can't exceed the default value because it's API limit. A key to extract partition key from JSON object. Default nil, which means partition key will be generated randomly. This loads AWS access credentials from an external process. AWS region of your stream. It should be in form like us-east-1, us-west-2. Default nil, which means try to find from environment variable AWS_REGION. Boolean, default true. If enabled, when after retrying, the next retrying checks the number of succeeded records on the former batch request and reset exponential backoff if there is any success. Because batch request could be composed by requests across shards, simple exponential backoff for the batch request wouldn't work some cases. The plugin will put multiple records to Amazon Kinesis Data Streams in batches using PutRecords. A set of records in a batch may fail for reasons documented in the Kinesis Service API Reference for PutRecords. Failed records will be retried retriesonbatch_request times The threshold for chunk flush performance check. Parameter type is float, not time, default: 20.0 (seconds) If chunk flush takes longer time than this threshold, fluentd logs warning message and increases metric fluentdoutputstatusslowflush_count. Name of the stream to put data. assumerolecredentials The duration, in seconds, of the role session (900-3600) A unique identifier that is used by third parties when assuming roles in their customers' accounts. An IAM policy in JSON format The Amazon Resource Name (ARN) of the role to assume An identifier for the assumed role session process_credentials Command more info: https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/ProcessCredentials.html
Project: Checkmk (Observability and Analysis / Observability)
File: 15514.md

key | value | date | 2024-03-08T10:06:58+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 2 compatible | no The legacy http monitoring plugin caused quite some trouble over the last years. This included lots of effort to add features or just simply fixing bugs. With the new plugin, the functionality is moved to maintainable and extendable code completely under control of Checkmk. This means also breaking changes with the old plugin: Some metrics are not available anymore as it has been known. We discovered that these are simply not directly understandable. Instead we will add metrics as needed in the future. Some metrics will already be added in this first release Some functionality has been a workaround and is now implemented directly into the new plugin. This makes it hard to migrate rules automatically. Users are now able to decide on their own which functionality should be in an own service. This means, that it is now possible to test the certificate validity and response times in one service, if needed. User are able to configure multiple http checks within one rule. You can provide standard settings to be used for all endpoints, and overwrite them per entry for each endpoint. Migrating manually makes absolute sense here. Please note that we will not remove the old plugin for now. We understand that you need some time to migrate your configurations. Nethertheless, we will deprecate the old plugin and eventually remove it from Checkmk.