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

title: HTTP Client description: Pull observability data from an server at a configured interval component_kind: source layout: component tags: ["http", "client", "scrape", "component", "source", "logs", "metrics", "traces"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Vector (Observability and Analysis / Observability)
File: greptimedb.md

title: GreptimeDB description: Writes metric data to component_kind: sink layout: component tags: ["greptimedb", "component", "sink", "storage", "time-series", "metrics"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_role.KubeRole.md

title: "Interface: KubeRole" linkTitle: "KubeRole" slug: "libk8srole.KubeRole" .KubeRole `KubeRole` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ rules: `Object` | Name | Type | | : | : | | `apiGroups` | `string`[] | | `nonResourceURLs` | `string`[] | | `resourceNames` | `string`[] | | `resources` | `string`[] | | `verbs` | `string`[] |
Project: Grafana Loki (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: VictoriaMetrics (Observability and Analysis / Observability)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Grafana (Observability and Analysis / Observability)
File: set-up-for-high-availability.md

aliases: ../administration/set-up-for-high-availability/ ../tutorials/ha_setup/ description: Learn how to set up Grafana to be highly available. keywords: grafana tutorials HA high availability labels: products: enterprise oss menuTitle: Set up HA title: Set up Grafana for high availability weight: 900 {{% admonition type="note" %}} To prevent duplicate alerts in Grafana high availability, additional steps are required. Please refer to for more information. {{% /admonition %}} Grafana uses an embedded sqlite3 database to store users, dashboards, and other persistent data by default. For high availability, you must use a shared database to store this data. This shared database can be either MySQL or Postgres. <div class="text-center"> <img src="/static/img/docs/tutorials/grafana-high-availability.png" max-width= "800px" class="center" /> </div> Before you complete the following tasks, configure a MySQL or Postgres database to be highly available. Configuring the MySQL or Postgres database for high availability is out of the scope of this guide, but you can find instructions online for each database. Once you have a Postgres or MySQL database available, you can configure your multiple Grafana instances to use a shared backend database. Grafana has default and custom configuration files, and you can update the database settings by updating your custom configuration file as described in the . Once configured to use a shared database, your multiple Grafana instances will persist all long-term data in that database. Grafana Alerting provides a high availability mode. It preserves the semantics of legacy dashboard alerting by executing all alerts on every server and by sending notifications only once per alert. Load distribution between servers is not supported at this time. For further information and instructions on setting up alerting high availability, refer to . Legacy dashboard alerts Legacy Grafana Alerting supports a limited form of high availability. In this model, alert notifications are deduplicated when running multiple servers. This means all alerts are executed on every server, but alert notifications are only sent once per alert. Grafana does not support load distribution between servers. Grafana Live works with limitations in highly available setup. For details, refer to the . Grafana uses auth token strategy with database by default. This means that a load balancer can send a user to any Grafana server without having to log in on each server.
Project: Netdata (Observability and Analysis / Observability)
File: web_log_1m_unmatched.md

In a webserver, all activity should be monitored. By default, most of the webservers log activity in an `access.log` file. The access log is a list of all requests for individual files that people or bots have requested from a website. Log File strings include notes about their requests for the HTML files and their embedded graphic images, along with any other associated files that are transmitted. The Netdata Agent calculates the percentage of unparsed log lines over the last minute. These are entries in the log file that didn't match in any of the common pattern operations (1XX, 2XX, etc) of the webserver. This can indicate an abnormal activity on your web server, or that your server is performing operations that you cannot monitor with the Agent. Web servers like NGINX and Apache2 give you the ability to modify the log patterns for each request. If you have done that, you also need to adjust the Netdata Agent to parse those patterns. Create a custom log format job You must create a new job in the `web_log` collector for your Agent. See how you can
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: BestPractices.md

sort: 32 weight: 32 title: VictoriaMetrics best practices menu: docs: parent: 'victoriametrics' weight: 32 aliases: /BestPractices.html It is recommended running the latest available release of VictoriaMetrics from , since it contains all the bugfixes and enhancements. There is no need to tune VictoriaMetrics because it uses reasonable defaults for command-line flags. These flags are automatically adjusted for the available CPU and RAM resources. There is no need in Operating System tuning because VictoriaMetrics is optimized for default OS settings. The only option is to increase the limit on the , so VictoriaMetrics could accept more incoming connections and could keep open more data files. The recommended filesystem for VictoriaMetrics is . If you plan to store more than 1TB of data on ext4 partition or plan to extend it to more than 16TB, then the following options are recommended to pass to mkfs.ext4: ```sh mkfs.ext4 ... -O 64bit,huge_file,extent -T huge ``` VictoriaMetrics should work OK with other filesystems too. VictoriaMetrics is production-ready for the following operating systems: Linux (Alpine, Ubuntu, Debian, RedHat, etc.) FreeBSD OpenBSD Solaris/SmartOS There is an experimental support of VictoriaMetrics components for Windows. VictoriaMetrics can run also on MacOS for testing and development purposes. Linux*: i386, amd64, arm, arm64, ppc64le FreeBSD*: i386, amd64, arm OpenBSD*: i386, amd64, arm Solaris/SmartOS*: i386, amd64 MacOS*: amd64, arm64 (for testing and development purposes) Windows*: amd64 It is safe to upgrade VictoriaMetrics to new versions unless the say otherwise. It is safe to skip multiple versions during the upgrade unless release notes say otherwise. It is recommended to perform regular upgrades to the latest version, since it may contain important bug fixes, performance optimizations or new features. It is also safe to downgrade to the previous version unless release notes say otherwise. The following steps must be performed during the upgrade / downgrade procedure: Send SIGINT signal to VictoriaMetrics process so that it is stopped gracefully. Wait until the process stops. This can take a few seconds. Start the upgraded VictoriaMetrics. VictoriaMetrics supports backups via and tools. There is also , which simplifies backup automation. There are the following channels for providing technical support for VictoriaMetrics: and We also provide .
Project: Grafana Tempo (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] --> Describe the solution you'd like <!-- A clear and concise description of what you want to happen. --> Describe alternatives you've considered <!-- A clear and concise description of any alternative solutions or features you've considered. --> Additional context <!-- Add any other context or screenshots about the feature request here. -->
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: AWS-SSM-experiments-tunables.md

It contains the aws-ssm specific experiment tunables. It stressed the `CPUCORE` cpu cores of the `EC2INSTANCEID` ec2 instance and `REGION` region for the `TOTALCHAOS_DURATION` duration. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: aws-ssm-chaos-by-id-sa experiments: name: aws-ssm-chaos-by-id spec: components: env: name: CPU_CORE value: '1' name: EC2INSTANCEID value: 'instance-01' name: REGION value: '<region of the EC2INSTANCEID>' name: TOTALCHAOSDURATION value: '60' ``` It stressed the `MEMORYPERCENTAGE` percentage of free space of the `EC2INSTANCEID` ec2 instance and `REGION` region for the `TOTALCHAOS_DURATION` duration. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: aws-ssm-chaos-by-id-sa experiments: name: aws-ssm-chaos-by-id specEC2INSTANCEID: components: env: name: MEMORY_PERCENTAGE value: '80' name: EC2INSTANCEID value: 'instance-01' name: REGION value: '<region of the EC2INSTANCEID>' name: TOTALCHAOSDURATION value: '60' ``` It contains the details of the SSM docs i.e, `name, type, the format of ssm-docs`. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: aws-ssm-chaos-by-id-sa experiments: name: aws-ssm-chaos-by-id spec: components: env: name: DOCUMENT_NAME value: 'AWS-SSM-Doc' name: DOCUMENT_FORMAT value: 'YAML' name: DOCUMENT_TYPE value: 'command' name: DOCUMENT_PATH value: '' name: EC2INSTANCEID value: 'instance-01' name: REGION value: '<region of the EC2INSTANCEID>' name: TOTALCHAOSDURATION value: '60' ``` It contains the `NUMBEROFWORKERS` workers for the stress. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: aws-ssm-chaos-by-id-sa experiments: name: aws-ssm-chaos-by-id specEC2INSTANCEID: components: env: name: NUMBEROFWORKERS value: '1' name: EC2INSTANCEID value: 'instance-01' name: REGION value: '<region of the EC2INSTANCEID>' name: TOTALCHAOSDURATION value: '60' ``` The multiple iterations of chaos can be tuned via setting `CHAOS_INTERVAL` ENV. Which defines the delay between each iteration of chaos. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: aws-ssm-chaos-by-id-sa experiments: name: aws-ssm-chaos-by-id specEC2INSTANCEID: components: env: name: CHAOS_INTERVAL value: '15' name: TOTALCHAOSDURATION value: '60' name: CPU_CORE value: '1' name: EC2INSTANCEID value: 'instance-01' name: REGION value: '<region of the EC2INSTANCEID>' ```
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: amplitude.md

title: Amplitude Integration sidebar_label: Amplitude hide_title: true You can integrate Flagsmith with Amplitude. You can automate AB tests by connecting the Flagsmith platform with Amplitude. The process is as follows: Get the Amplitude API key for your Amplitude project from the Amplitude Project page (Settings > Projects > Your Project > General tab) Add the Amplitude API key into Flagsmith (Integrations > Add Amplitude Integration) Set the Base URL relevant to your Amplitude project: `https://api2.amplitude.com` or `https://api.eu.amplitude.com` depending on whether you are using the US or EU region. Do not include a trailing slash - copy and paste the urls as they appear here. All API calls generated by the Flagsmith SDK to the `Get Identity Flags` endpoint will send a full set of flag evaluations for that particular user to the Amplitude :::tip For flags that contain remote config values, Flagsmith will pass the value of the flag to Amplitude if the flag is `enabled`. If the flag has no remote config value, Flagsmith will just pass the boolean state for the flag. ::: Identity flag values are passed into Amplitude. If we make the call to the Flagsmith API to get the flags for an Identity: ```bash curl 'https://edge.api.flagsmith.com/api/v1/identities/?identifier=developmentuser123456' \ -H 'x-environment-key: 8KzETdDeMY7xkqkSkY3Gsg' ``` And then take a look in our Amplitude dashboard, you can see the user and the flag data that has been sent to the Amplitude platform. Once the integration has been set up, you can start segmenting your Amplitude identities based on the flags that they saw. This means you can run AB tests driven by Flagsmith segments, and have the data show up automatically in Amplitude. You have to identify users on both platforms in the same way. The Flagsmith `Identity ID` must be the same as the Amplitude `user_id`.
Project: Cortex (Observability and Analysis / Observability)
File: BENCHMARK.md

Validating the Kubernetes Swagger API ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 8549863982 ns/op 7067424936 B/op 59583275 allocs/op ``` ``` go test -bench Spec goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 4064535557 ns/op 3379715592 B/op 25320330 allocs/op ``` ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 3758414145 ns/op 2593881496 B/op 17111373 allocs/op ```
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: redis.md

title: Redis weight: 200 generated_file: true Based on the . Available in Logging operator version 4.4 and later. {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: SyslogNGOutput metadata: name: redis namespace: default spec: redis: host: 127.0.0.1 port: 6379 retries: 3 throttle: 0 time-reopen: 60 workers: 1 {{</ highlight >}} For details on the available options of the output, see the . Batching parameters The password used for authentication on a password-protected Redis server. The Redis command to execute, for example, LPUSH, INCR, or HINCRBY. Using the HINCRBY command with an increment value of 1 allows you to create various statistics. For example, the `command("HINCRBY" "${HOST}/programs" "${PROGRAM}" "1")` command counts the number of log messages on each host for each program. Default: "" 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 The hostname or IP address of the Redis server. Default: 127.0.0.1 The number of messages that the output queue can store. Persistname The port number of the Redis server. Default: 6379 Internal rendered form of the CommandAndArguments field If syslog-ng OSE cannot send a message, it will try again until the number of attempts reaches `retries()`. Default: 3 Sets the maximum number of messages sent to the destination per second. Use this output-rate-limiting functionality only when using disk-buffer as well to avoid the risk of losing messages. Specifying 0 or a lower value sets the output limit to unlimited. Default: 0 The time to wait in seconds before a dead connection is reestablished. Default: 60 Specifies the number of worker threads (at least 1) that syslog-ng OSE uses to send messages to the server. Increasing the number of worker threads can drastically improve the performance of the destination. Default: 1
Project: LinDB (Observability and Analysis / Observability)
File: CHANGELOG-1.0.md

See . [bug]: fix storage panic when write old data point by @stone1100 in #1020 See . [chore]: add style lint by @stone1100 in #977 [enhance]: add iconfont by @stone1100 in #979 [feat]: CI support arm64 images by @dongjiang1989 in #981 [bug]: fix theme color palette setting by @stone1100 in #978 [bug]: use metric level namespace if set by @stone1100 in #980 [bug]: fix data explore not support namespace by @stone1100 in #982 [bug]: fix diff namespace conflict by @stone1100 in #983 See . [feat]: support select *(query all fields) by @stone1100 in #974 [chore]: build darwin arm64 package by @stone1100 in #975 See . [bug]: darwin package no cpu stats data by @stone1100 in #968 [bug]: lost web console when build package via github action by @stone1100 in #969 [bug]: fix build darwin package fail by @stone1100 in #971 See . [enhance]: consume group wait strategy when WAL is empty by @stone1100 in #960 [chore]: use golangci/golangci-lint-action by @damnever in #956 [chore]: add twitter badge to readme by @stone1100 in #958 See . docker hub sync github actions join file paths fix get diff agg result using diff group by interval See . support auto fill group by time interval based on query range read config from env print config value when server startup support release with a docker image print error message when handle http request failure add cli tools to docker image need to check rollup Interval when memory database refreshing check database's intervals if valid fix time picker no display last 30 days cannot create database if storage not exist got unexpected result when async load family data fix cannot rollup data for windows fix miss some source family data when rollup job @Sn0rt made their first contribution in https://github.com/lindb/lindb/pull/927 See . database level read/write limit configure slow sql metric chart show error message if query fail fix nil point when parse wrong sql See . cross multiple IDCs query; configure logic database/broker cluster; add root server for cross IDCs; explore root's coordinate metadata; root self-monitoring; view root state; view admin UI based env vars; de-register broker node when shutdown; stop write ahead log too slow; refactor query stats metric; refactor explain query stats; fix directory traversal security issue; fix alive/create/expire task metric no data; See . web admin console support zh_CN; add detail doc link for each page; recover database metadata from local storage if etcd data lost; print version format; lind-cli logmsg via file; chart's y-axes start with 0 if min value <=0; fix delete active wal when not set write ahead time; Metadata coordinator(database/broker/storage/master etc.); Distributed query engine, SQL supported; Data supports distributed storage; Supports write ahead log;