cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana (Observability and Analysis / Observability)
File: build-first-dashboard.md

aliases: ../guides/getting_started/ ../guides/gettingstarted/ getting-started/ description: Learn how to get started with Grafana by adding a preconfigured dashboard. labels: products: enterprise oss title: Build your first dashboard weight: 200 This topic helps you get started with Grafana and build your first dashboard using the built-in `Grafana` data source. To learn more about Grafana, refer to . {{% admonition type="note" %}} Grafana also offers a to help getting started even easier and faster. You can install Grafana to self-host or get a free Grafana Cloud account. {{% /admonition %}} Grafana can be installed on many different operating systems. For a list of the minimum hardware and software requirements, as well as instructions on installing Grafana, refer to . To sign in to Grafana for the first time: Open your web browser and go to http://localhost:3000/. The default HTTP port that Grafana listens to is `3000` unless you have configured a different port. On the sign-in page, enter `admin` for both the username and password. Click Sign in. If successful, you'll see a prompt to change the password. Click OK on the prompt and change your password. {{% admonition type="note" %}} We strongly recommend that you change the default administrator password. {{% /admonition %}} If you've already set up a data source that you know how to query, refer to instead. To create your first dashboard using the built-in `-- Grafana --` data source: Click Dashboards in the left-side menu. On the Dashboards page, click New and select New Dashboard from the drop-down menu. On the dashboard, click + Add visualization. In the dialog box that opens, click `-- Grafana --`: {{< figure class="float-right" src="/media/docs/grafana/dashboards/screenshot-data-source-selector-10.0.png" max-width="800px" alt="Select data source dialog box" >}} This configures your and generates the Random Walk dashboard. Click the Refresh dashboard icon to query the data source. When you've finished editing your panel, click Save to save the dashboard. Alternatively, click Apply if you want to see your changes applied to the dashboard first. Then click the save icon in the dashboard header. Add a descriptive title for the dashboard, or have Grafana create one using , and then click Save. Congratulations, you have created your first dashboard and it's displaying results. Continue to experiment with what you have built, try the or another visualization feature. Refer to for a list of supported data sources and instructions on how to . The following topics will be of interest to you: The following topics are of interest to Grafana server admin users:
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-deployment-mode.md

aliases: ../../operators-guide/deploy-grafana-mimir/jsonnet/configure-deployment-mode/ description: Learn how to configure Grafana Mimir deployment mode. menuTitle: Configure deployment mode title: Configure deployment mode weight: 40 Grafana Mimir supports multiple . By default, the provided Jsonnet deploys in microservices mode. Monolithic mode is not supported in Jsonnet. {{< admonition type="warning" >}} Read-Write deployment mode is experimental. {{< /admonition >}} Read-write deployment mode requires that you use multi-zone ingesters and multi-zone store gateways. Additionally, rule evaluation is performed within `mimir-backend`, so you must disable ruler remote evaluation. You can set the deployment mode via the `deployment_mode` configuration variable: ```jsonnet { _config+:: { deployment_mode: 'read-write', mimirwritereplicas: 15, mimirreadreplicas: 6, mimirbackendreplicas: 9, // Requirements. multizoneingester_enabled: true, multizonestoregatewayenabled: true, rulerremoteevaluation_enabled: false, // Disable microservices autoscaling. autoscalingquerierenabled: false, autoscalingrulerquerier_enabled: false, } } ``` You can configure autoscaling for the read path: ```jsonnet { _config+:: { autoscalingmimirread_enabled: true, autoscalingmimirreadminreplicas: 2, autoscalingmimirreadmaxreplicas: 20, } } ``` CLI flags for read-write components are inherited from the microservices. For example: ```jsonnet { _config+:: { // This change also applies to mimir-backend. storegatewayargs+:: { 'blocks-storage.bucket-store.sync-interval': '5m', }, } } ``` Pitfall: Kubernetes resources overrides are not inherited. Remember to apply overrides to both microservices and read-write components, if you make changes to any of the following items: Container specification, for example environment variables Deployment StatefulSet Service PodDisruptionBudget For example: ```jsonnet { _config+:: { // This change will NOT be applied to mimir-write too. ingester_container+:: container.withEnvMixin( [envVar.new('GOGC', '50')] ), mimirwritecontainer+:: container.withEnvMixin( [envVar.new('GOGC', '50')] ), } } ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16475.md

key | value | date | 2024-03-12T09:59:13+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | yes This werk extends the modify and delete endpoints for downtimes with filters for hostgroups and servicegroups, similar to the create endpoints.
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: kubectl.md

layout: default title: New pod startup SLO description: "" permalink: /kubectl parent: Writing policies nav_order: 1 {: .no_toc } {: .no_toc .text-delta } TOC {:toc} Let's say we want to make sure that a new pod you create responds quickly enough. ```yaml scenarios: name: Test deployment SLO description: > Verifies that after a new deployment and a service are scheduled, it can be called within 30 seconds. steps: kubectl: autoDelete: true action: apply payload: | apiVersion: v1 kind: ConfigMap metadata: name: sealpolicy data: policy.yml: |- scenarios: name: "noop" steps: wait: seconds: 1000 apiVersion: apps/v1 kind: Deployment metadata: name: powerfulseal spec: replicas: 1 template: metadata: labels: name: powerfulseal spec: containers: name: powerfulseal image: powerfulseal/powerfulseal:3.1.1 args: autonomous --policy-file=/policy.yml volumeMounts: name: policyfile mountPath: /policy.yml subPath: policy.yml volumes: name: policyfile configMap: name: sealpolicy apiVersion: v1 kind: Service metadata: name: powerfulseal spec: ports: name: powerfulseal port: 8000 selector: name: powerfulseal wait: seconds: 30 probeHTTP: target: service: name: some-service namespace: default port: 8000 protocol: http ```
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: google_pubsub.md

sidebar_position: 7 The PubSub exporter will collect the data and publish an event on the topic for each evaluation we receive. ```go ffclient.Config{ // ... cfg, _ := config.LoadDefaultConfig(context.TODO()) DataExporter: ffclient.DataExporter{ // ... Exporter: &pubsubexporter.Exporter{ ProjectID: "project-id", // required Topic: "topic", // required Options: []option.ClientOption{...}, PublishSettings: &pubsub.PublishSettings{...}, EnableMessageOrdering: true, }, }, // ... } ``` | Field | Description | |-|| | `ProjectID ` | ID of GCP project.<br/>You can find it in your GCP console | | `Topic ` | Name of topic on which messages will be published | | `Options` | PubSub client options (see ) | | `PublishSettings` | Topic related settings (see ) | | `EnableMessageOrdering` | Enables delivery of ordered keys | Check the .
Project: Checkmk (Observability and Analysis / Observability)
File: 16684.md

key | value | date | 2024-04-09T10:11:41+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | no This only affects plugin developers using the new ruleset API. The `Dictionary`s attribute `deprecated_elements` is renamed to `ignored_elements`. It is validated that no present elements are marked as 'ignored'.
Project: Vector (Observability and Analysis / Observability)
File: agent.md

title: Agent Architecture description: Run Vector at your edge to democratize processing. weight: 2 {{< warning >}} If you have a complex production environment that makes deploying Vector as an agent difficult, consider starting with the or combine them for the . {{< /warning >}} This agent architecture deploys Vector as an on each node for local data collection and processing. Data can be collected directly by Vector, indirectly through another agent, or both simultaneously. Data processing can happen on the node or in an aggregator. We recommend this architecture for: Simple environments that do not require . Use cases that do not need to hold onto data for long periods, such as fast, stateless processing and streaming delivery. (i.e., merging multi-line logs or aggregating host specific metrics). Operators that can make node-level changes without a lot of friction. If your use case violates these recommendations, consider the or architectures. Only agents that perform ; with all other agents. . If you need complex processing, consider the . . If you need long-lived batching consider the . Buffer your data in memory; do not buffer on disk. If you need durability, consider the . {{< info >}} See the for more detail. {{< /info >}} If the is unacceptable, consider the , which deploys Vector across multiple nodes in a . Enable to mitigate . Route dropped events to mitigate . {{< info >}} See the for more detail. {{< /info >}} . . . . {{< info >}} See the for more detail. {{< /info >}} Limit the Vector agent to and . If your Vector agent requires more than this, shift resource-intensive processing to your . {{< info >}} See the for more detail. {{< /info >}} Roll out . Following the roll-out and . {{< info >}} See the for more detail. {{< /info >}} We deploying Vector alongside other agents that with specific systems and produce unique data. Otherwise, Vector should the agent. See the section for more detail. As a general rule of thumb, agents should not hold onto data. Furthermore, processing and delivery of data should be fast and streaming. If you need to perform complex processing or long-lived batching, use the . For easy setup and maintenance of this architecture, consider the Vectors or . These are free best effort channels. For enterprise needs, consider Datadog Observability Pipelines, which comes with enterprise-level support.
Project: HertzBeat (Observability and Analysis / Observability)
File: 2022-09-04-hertzbeat-v1.1.3.md

title: Cloud monitoring system HertzBeat v1.1.3 released! author: tom author_title: tom author_url: https://github.com/tomsun28 authorimageurl: https://avatars.githubusercontent.com/u/24788200?s=400&v=4 tags: [opensource] Home: hertzbeat.com | tancloud.cn Hi guys! HertzBeat v1.1.3 is coming. This version supports kafka monitor, ssl certificate expired monitor and more. Fixed several bugs and improved the overall stable usability. Only one docker command is needed to install and experience hertzbeat `docker run -d -p 1157:1157 --name hertzbeat apache/hertzbeat` Thanks to the contributors! Feature contribute by @wang1027-wqh issue by @ericfrol suggest by @noear issue by @ericfrol Bugfix. contribute by @woshiniusange . issue by https://gitee.com/hellobrotherniu issue by https://gitee.com/hellobrotherniu Online https://console.tancloud.cn. Have Fun!
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-host_related_template.md

category: Host apiurl: '/api/v1/host/#{host_id}/template' title: "Get bind Template List of Host" type: 'GET' sample_doc: 'host.html' layout: default Required ex. /api/v1/host/1647/template tpl_name: template name ```Status: 200``` ```[ { "id": 125, "tpl_name": "tplA", "parent_id": 0, "action_id": 99, "create_user": "root" }, { "id": 142, "tpl_name": "tplB", "parent_id": 0, "action_id": 111, "create_user": "root" }, { "id": 180, "tpl_name": "tplC", "parent_id": 0, "action_id": 142, "create_user": "root" } ]```
Project: Headlamp (Observability and Analysis / Observability)
File: backend.md

title: Backend weight: 5 Headlamp's backend is written in Go and is in charge of redirecting the client requests to the right clusters, as well as to return any available plugins for the client to use. The backend most basic and essential function is to read the cluster information from the given configuration, and set up proxies to the defined clusters as well as endpoints to them. This means that instead of having a set of endpoints related to the functionality available to the client, it simply redirects the requests to the defined proxies. The backend (Headlamp's server) can be quickly built using: ```bash make backend ``` Once built, it can be run in development mode (insecure / don't use in production) using: ```bash make run-backend ``` To lint the backend/ code. ```bash make backend-lint ``` To format the backend code. ```bash make backend-format ``` ```bash make backend-test ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-10-dedupe-transform.md

date: "2020-04-16" title: "New Dedupe Transform" description: "Shed duplicate logs" authors: ["binarylogic"] pr_numbers: [1848] release: "0.9.0" hideonrelease_notes: false badges: type: new feature domains: ["sources"] sources: ["vector"] For certain use cases, log deduplication can be a useful tool. Not only does this promote your data integrity, but it can help protect against upstream mistakes that accidentally duplicate logs. This mistake can easily double (or more!) your log volume. To protect against this you can use our new . Simply add the transform to your pipeline: ```toml [transforms.mytransformid] type = "dedupe" # required inputs = ["my-source-id"] # required fields.match = ["timestamp", "host", "message"] # optional, default ``` {{< success >}} The `fields.match` option lets you control which fields are compared to determine if events are equal. {{< /success >}}
Project: Kiali (Observability and Analysis / Observability)
File: README.md

This folder contains tools for maintainers of the Kiali project. There's two cli tools to help with testing large graph topologies without needing to deploy the underlying resources. Note: You do not need to run the generator before running the proxy. The proxy server will run the generator itself and serve up the mock data from memory by default. If you are testing locally, you probably want to use the proxy. If you want to output the mock data as a json file, then run the generator. The proxy server runs an http proxy that intercepts all `/api/namespaces/graph` calls and returns mock graph data. The rest of the api calls are passed through to the kiali api. To test the kiali ui using the proxy server, you should start the proxy server then, in the kiali ui's `package.json`, replace the `proxy` field with the address of the proxy server e.g. `"proxy": "https://localhost:10201"`. Finally run `yarn start` and navigate to local node server endpoint: `http://localhost:3000`. When you navigate to the graph page, you should see graph rendered with the mock data. Running the following command will start the proxy server in https mode. ```bash go run tools/cmd/proxy/main.go <kiali-url> --apps 50 --box --https ``` For more usage information: ```bash go run tools/cmd/proxy/main.go --help ``` The generator creates a json file with a mock `/api/namespaces/graph` response. Running the following command will create a json file with 50 apps (workloads + services). There is some randomness in the graph generation so running the command multiple times with the same options will yield different results. ```bash go run tools/cmd/generate/main.go --apps 50 --box ``` For more usage information: ```bash go run tools/cmd/generate/main.go --help ```
Project: Grafana (Observability and Analysis / Observability)
File: declare-incident-from-alert.md

aliases: ../../alerting/alerting-rules/declare-incident-from-alert/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alerting-rules/declare-incident-from-alert/ canonical: https://grafana.com/docs/grafana/latest/alerting/manage-notifications/declare-incident-from-alert/ description: Declare an incident from a firing alert keywords: grafana alert rules incident labels: products: cloud enterprise oss title: Declare incidents from firing alerts weight: 1010 Declare an incident from a firing alert to streamline your alert to incident workflow. Ensure you have Grafana Incident installed You must have a firing alert To declare an incident from a firing alert, complete the following steps. Navigate to Alerts & Incidents -> Alerting -> Alert rules. From the Alert rules list view, click the firing alert that you want to declare an incident for. Note: You can also access Declare Incident from the alert details page. Click Declare Incident. The Declare Incident pop-up opens in the Grafana Incident application. In the Declare Incident pop-up, enter what's going on. Note: This field is pre-filled with the name of the alert rule, but you can edit it as required. The alert rule is also linked to the incident. Select a severity. Add labels, as required. Click More options to include a channel prefix and status. Click Declare Incident. View and track the incident in the Grafana Incident application. For more information, refer to
Project: Thanos (Observability and Analysis / Observability)
File: multi-tenancy.md

Thanos supports multi-tenancy by using external labels. For such use cases, the based approach with layered is recommended. You can also use the however, we don't recommend it to achieve a global view of data of a single-tenant. Also note that, multi-tenancy may also be achievable if ingestion is not user-controlled, as then enforcing of labels, for example using the (please thoroughly understand the mechanism if intending to employ this mechanism, as the wrong configuration could leak data).
Project: Kiali (Observability and Analysis / Observability)
File: SECURITY.md

Kiali takes security seriously and encourages users to report security concerns. If you run a security scan on Kiali software that automatically generates a list of potential vulnerabilities and would like to report this security scan report to the Kiali team, we ask that you first verify that your scan is correctly validating the latest release and that the list of results is valid, contains no duplicates, and the reported vulnerabilities truly affect Kiali. Security report investigation often takes priority over scheduled work and can be time consuming for the Kiali maintainers to research and validate. So, please verify that your submitted report accurately reflects the Kiali software being scanned, and that the reported security issue(s) actually affect Kiali or one of its dependencies. For current security bulletins see https://kiali.io/news/security-bulletins Kiali provides security updates for versions used in supported versions of the following products: Istio Red Hat OpenShift ServiceMesh Please let us know in your report if you are reporting a Kiali security issue for a supported environment outside of those listed above. Upstream releases are frequent and include security fixes as soon as possible. Please send mail to kiali-security@googlegroups.com to report a security issue found in Kiali. We will update you via e-mail when the issue has been evaluated. Please do NOT reveal any potential security issue in a Kiali github issue, or on other Kiali mailing lists.
Project: Netdata (Observability and Analysis / Observability)
File: bcache_cache_errors.md

This alert is triggered when the number of read races in the last minute on a `bcache` system has increased. A read race occurs when a `bucket` is reused and invalidated while it's being read from the cache. In this situation, the data is reread from the slower backing device. `bcache` is a cache within the block layer of the Linux kernel. It enables fast storage devices, such as SSDs (Solid State Drives), to act as a cache for slower storage devices like HDDs (Hard Disk Drives). This creates hybrid volumes with improved performance. A cache device is usually divided into `buckets` that match the physical disk's erase blocks. Verify the current `bcache` cache errors: ``` grep bcachecacheerrors /sys/fs/bcache//stats_total/ ``` This command will show the total number of cache errors for all `bcache` devices. Identify the affected backing device: You can determine the affected backing device by checking the `/sys/fs/bcache` directory. Look for the symbolic link that points to the problematic device. ``` ls -l /sys/fs/bcache ``` This command will show the list of devices with corresponding names. Monitor the cache device's performance: Use `iostat` to check the cache device's I/O performance. ``` iostat -x -h -p /dev/YOURCACHEDEVICE ``` Note that you should replace `YOURCACHEDEVICE` with the actual cache device name. Check the utilization of the cache and backing devices: Use the following commands to check the utilization percentage of the cache and backing devices: ``` cat /sys/block/YOURCACHEDEVICE/bcache/utilization cat /sys/block/YOURBACKINGDEVICE/bcache/utilization ``` Replace `YOURCACHEDEVICE` and `YOURBACKINGDEVICE` with the respective device names. Optimize the cache: If the cache utilization is high, consider increasing the cache size or adding more cache devices. If the cache device is heavily utilized, consider upgrading it to a faster SSD. In case the read races persist, consider using a . You may also need to review your system's overall I/O load and adjust your caching strategy accordingly.
Project: Netdata (Observability and Analysis / Observability)
File: 10min_dbengine_global_fs_errors.md

The Database Engine works like a traditional database. It dedicates a certain amount of RAM to data caching and indexing, while the rest of the data resides compressed on disk. Unlike other memory modes, the amount of historical metrics stored is based on the amount of disk space you allocate and the effective compression ratio, not a fixed number of metrics collected. By using both RAM and disk space, the database engine allows for long-term storage of per-second metrics inside of the Netdata agent itself. Netdata monitors the number of filesystem errors in the last 10 minutes. The Dbengine is experiencing filesystem errors (too many open files, wrong permissions, etc.) This alert is triggered in warning state when the number of filesystem errors is greater than 0.
Project: Vector (Observability and Analysis / Observability)
File: validating.md

title: Validating weight: 5 tags: ["validate", "configuration"] Vector provides a subcommand, , that checks the validity of your Vector configuration and exits. Here's an example: ```bash vector validate /etc/vector/vector.yaml ``` You can also check multiple files: ```bash vector validate /etc/vector/vector*.toml ``` The subcommand performs several sets of checks on the configuration you point it to. If validation succeeds, Vector exits with a code of `0`; if it fails, it exits with a code of `78`. At any time, you can see documentation for the command by running `vector validate --help`. These checks verify the correctness of fields for [components] defined within all configuration files, including: That all of the [sources], [transforms], and [sinks] include all required fields. All fields are of the proper type. These checks verify that the configuration file contains a valid topology: At least one is defined At least one is defined All inputs for each topology component (specified using the `inputs` parameter) contain at least one value. All inputs refer to valid and upstream [sources] or [transforms]. Finally, these checks ensure that Vector is running in an environment that can support the configured topology: All components have the pre-requisites to run, e.g. data directories exist and are writable. All sinks can connect to their specified targets. These environment checks can be disabled using the flag: ```bash vector validate --no-environment /etc/vector/vector.yaml ``` To validate the vector configuration even if the health-checked endpoints are not reachable (for example, from a local workstation), but still run all the other environment checks, use the flag: ```bash vector validate --skip-healthchecks /etc/vector/vector.yaml ``` Note: The configured `data_dir` must still be writeable.