cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana (Observability and Analysis / Observability)
File: curl-examples.md

aliases: ../../http_api/curl-examples/ canonical: /docs/grafana/latest/developers/http_api/curl-examples/ description: cURL examples keywords: grafana http documentation api curl labels: products: enterprise oss title: cURL examples This page provides examples of calls to the Grafana API using cURL. The most basic example for a dashboard for which there is no authentication. You can test the following on your local machine, assuming a default installation and anonymous access enabled, required: ``` curl http://localhost:3000/api/search ``` Here's a cURL command that works for getting the home dashboard when you are running Grafana locally with enabled using the default admin credentials: ``` curl http://admin:admin@localhost:3000/api/search ``` To pass a username and password with , encode them as base64. You can't use authorization tokens in the request. For example, to given a username of `user` and password of `password`, use: ``` curl --location '<grafana_url>/api/access-control/builtin-roles' --user 'user:password' ```
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-5-5.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.5.5 <!-- Auto generated by update changelog github action --> Azure Monitor: Include datasource ref when interpolating variables. , CloudWatch: Add multi-value template variable support for log group names in logs query builder. , Cloudwatch: Add template variable query function for listing log groups. , Alerting: Do not overwrite existing alert rule condition. , Alerting: Remove double quotes from matchers. ,
Project: Grafana Tempo (Observability and Analysis / Observability)
File: WORKFLOW.md

This document is based on . We assume good faith and intend to keep all processes as lightweight as possible but as specific as required. In case of disagreements about anything in this document, GOVERNANCE.md applies. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in . Git and are used throughout this document. Team members and their access to repositories is maintained through . Team maintainers add and remove team members as outlined in GOVERNANCE.md. Examples of proposed changes are overarching architecture, component design, and specific code or graphical elements. Proposed changes SHOULD cover the big picture and intention, but individual parts SHOULD be split into the smallest possible changes. Changes SHOULD be based on and target the main branch. Depending on size of the proposed change, each change SHOULD be discussed, in increasing order of change size and complexity: Directly in a PR (Pull Request) - this MAY be done, but SHOULD not be the common case. Issue Developer mailing list Design document, shared via Google Docs, accessible to at least all team members. Significant changes MUST be discussed and agreed upon with the relevant subsystem maintainers. Depending on the size and complexity of a PR, different requirements MUST be applied. Any team member contributing substantially to a PR MUST NOT count against review requirements. Commits MUST be merged into main using PRs. They MUST NOT be pushed to main directly. Every merge MUST be approved by at least one team member. Non-trivial changes MUST be approved by at least two team members, or one subsystem maintainer. Significant changes MUST be approved by at least two team members, AND the relevant subsystem maintainer. PRs MUST be and via GitHubs review system. Reviewers MAY write comments if approving Reviewers MUST write comments if rejecting a PR or if requesting changes. Once a PR is approved as per above, any team member MAY merge the PR. Grafana uses trunk-based development. In particular, we found that the following principles match how we work: Main and release branches MUST always build without failure. Branches SHOULD be merged often. Larger changes SHOULD be activated with feature flags until they are ready. Long-lived development branches SHOULD be avoided. Changes MAY be enabled by default once they are in a complete state Changes which span multiple PRs MUST be described in an overarching issue or Google Doc. Releases MUST follow in naming and SHOULD follow Semantic Versioning as closely as reasonably possible for non-library software.
Project: HertzBeat (Observability and Analysis / Observability)
File: rainbond-deploy.md

id: rainbond-deploy title: Use Rainbond Deploy HertzBeat sidebar_label: Install via Rainbond If you are unfamiliar with Kubernetes, and want to install HertzBeat in Kubernetes, you can use Rainbond to deploy. Rainbond is a cloud-native application management platform built on Kubernetes and simplifies the application deployment to Kubernetes. To install Rainbond, please refer to After logging in Rainbond, click Market in the left menu, switch to open source app store, and search HertzBeat in the search box, and click the Install button. Fill in the following information, and click Confirm button to install. Team: select a team or create a new team Cluster: select a cluster Application: select an application or create a new application Version: select a version After installation, HertzBeat can be accessed via the Access button. :::tip HertzBeat installed via Rainbond, External Mysql database and Redis and IoTDB are used by default, The HertzBeat configuration file is also mounted, which can be modified in `Components -> Environment Configuration -> Configuration File Settings`. :::
Project: Checkmk (Observability and Analysis / Observability)
File: 16630.md

key | value | date | 2024-03-18T09:19:03+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The active check check_mail can be configured to move mail messages from the inbox to a subfolder via the options "Forward mails as events to Event Console" > "Cleanup messages" > "Move to subfolder". For IMAP the copying of mails crashed when there were no mails available in the inbox. This is fixed to skipping the copy command in case there are no mails given.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: CLI.md

description: Flagsmith Command Line Interface (CLI) sidebar_label: CLI sidebar_position: 6 Flagsmith has a that you can use to help in your development workflows. Install globally: ```bash npm install -g flagsmith-cli ``` ```bash USAGE $ flagsmith get [ENVIRONMENT] [-o <value>] [-a <value>] [-i <value>] ARGUMENTS ENVIRONMENT The flagsmith environment key to use, defaults to the environment variable FLAGSMITH_ENVIRONMENT FLAGS -a, --api=<value> The API URL to fetch the feature flags from -i, --identity=<value> The identity for which to fetch feature flags -o, --output=<value> [default: ./flagsmith.json] The file path output DESCRIPTION Retrieve flagsmith features from the Flagsmith API and output them to a file. EXAMPLES $ FLAGSMITH_ENVIRONMENT=x flagsmith get $ flagsmith get <ENVIRONMENT_ID> $ flagsmith get --o ./my-file.json $ flagsmith get --a https://flagsmith.example.com/api/v1/ $ flagsmith get --i flagsmith_identity ```
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: environment-settings.md

title: Environment Settings This setting allows legacy environments to manually choose to update the hashing algorithm used by the engine when evaluating multivariate and percentage splits. Enabling this setting ensures that identities that are evaluated across the Core API, Edge API and local evaluation mode in our server side SDKs receive the same multivariate variations and appear in the same segments that use the percentage split operator. All new environments are created with this setting enabled by default. :::caution This will result in identities receiving different variations and being evaluated in different segments (that use the % split operator) when evaluated against the remote API. Evaluations in local evaluation mode will not be affected. ::: When creating or updating a segment, you can enhance its information by adding previously created and enabled metadata fields. To create and enable this you can do it in the metadata tab on the project settings page. If you have metadata for features, it will create a list of fields that can be filled, saved, and will be stored with the feature's save flag.
Project: Checkmk (Observability and Analysis / Observability)
File: 16477.md

key | value | date | 2024-03-18T09:17:45+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This Werk fixes a crash in the Nutanix "NTNX Storage", "Storage Pool" and "Container" services. It also adds the option to update the naming of the "Prism Alerts", "Prism Cluster", "Container" and "Storage Pool" services to be more consistent with the other Nutanix services. The new names will be automatically used in new installations.
Project: Headlamp (Observability and Analysis / Observability)
File: metrics-server.md

title: Kubernetes Metrics Server linkTitle: Metrics Server Headlamp can show information for resources usage if the Metrics Server is installed. If the Metrics Server is not installed, then a related notice is displayed as shown in the following screenshot: To read more about metrics server check out the . If you are running Minikube, then you can install the Metrics Server by enabling the . i.e.: ```shell minikube addons enable metrics-server ```
Project: Hubble (Observability and Analysis / Observability)
File: TROUBLESHOOTING.md

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

[% if entry.metrics.scopes %] [% if entry.metrics.folding.enabled and not clean %] {% details summary="[[ entry.metrics.folding.title ]]" %} [% endif %] Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. [[ entry.metrics.description ]] [% for scope in entry.metrics.scopes %] [[ scope.description ]] [% if scope.labels %] Labels: | Label | Description | |:--|:-| [% for label in scope.labels %] | [[ strfy(label.name) ]] | [[ strfy(label.description) ]] | [% endfor %] [% else %] This scope has no labels. [% endif %] Metrics: | Metric | Dimensions | Unit |[% for a in entry.metrics.availability %] [[ a ]] |[% endfor %] |:|:-|:-|[% for a in entry.metrics.availability %]::|[% endfor %] [% for metric in scope.metrics %] | ] | [% endif %] |[% endfor %] [% endfor %] [% endfor %] [% if entry.metrics.folding.enabled and not clean %] {% /details %} [% endif %] [% else %] [[ entry.metrics.description ]] [% endif %]
Project: OpenCost (Observability and Analysis / Continuous Optimization)
File: MAINTAINERS.md

Official list of . are granted Triage permissions for the OpenCost repositories. The describes the process for becoming a committer and maintainer of the project. | Maintainer | GitHub ID | Affiliation | Email | | | | -- | -- | | Ajay Tripathy | @AjayTripathy | Kubecost | <Ajay@kubecost.com> | | Alex Meijer | @ameijer | Kubecost | <ameijer@kubecost.com> | | Artur Khantimirov | @r2k1 | Microsoft | | | Matt Bolt | @mbolt35 | Kubecost | <matt@kubecost.com> | | Matt Ray | @mattray | Kubecost | <mattray@kubecost.com> | | Niko Kovacevic | @nikovacevic | Kubecost | <niko@kubecost.com> | | Sean Holcomb | @Sean-Holcomb | Kubecost | <Sean@kubecost.com> | | Thomas Evans | @teevans | Kubecost | <thomas@kubecost.com> | We would like to acknowledge previous committers and their huge contributions to our collective success: | Maintainer | GitHub ID | Affiliation | Email | | | | -- | -- | | Michael Dresser | @michaelmdresser | Kubecost | <michaelmdresser@gmail.com> |
Project: Vector (Observability and Analysis / Observability)
File: rpm.md

title: Install Vector using RPM short: RPM weight: 8 RPM Package Manager is a free and open source package management system for installing and managing software on Fedora, CentOS, OpenSUSE, OpenMandriva, Red Hat Enterprise Linux, and related Linux-based systems. This covers installing and managing Vector through the RPM package repository. ```shell sudo rpm -i https://yum.vector.dev/stable/vector-0/{arch}/vector-{{< version >}}-1.{arch}.rpm ``` Make sure to replace `{arch}` with one of the following: `x86_64` `aarch64` `armv7hl` {{< tabs default="Uninstall Vector" >}} {{< tab title="Uninstall Vector" >}} ```shell sudo rpm -e vector ``` {{< /tab >}} {{< /tabs >}} {{< jump "/docs/administration/management" "apt-dpkg-rpm-yum-pacman" >}}
Project: HertzBeat (Observability and Analysis / Observability)
File: ping.md

id: ping title: MonitoringPING connectivity sidebar_label: PING connectivity keywords: [open source monitoring tool, open source network monitoring tool, monitoring ping metrics] Ping the opposite end HOST address and judge its connectivity. | Parameter name | Parameter help description | | -- | -- | | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Ping timeout | Set the timeout when Ping does not respond to data, unit:ms, default: 3000ms | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | responseTime | ms | Website response time | Ping connectivity monitoring exception when installing hertzbeat for package deployment. The hertzbeat installed and deployed by the installation package is not available for ping connectivity monitoring, but local direct ping is available The deployment of the installation package requires configuring the root permission of the Java virtual machine to start hertzbeat to use ICMP. If the root permission is not enabled, judge whether port 7 of telnet opposite end is opened. When you install HertzBeat via DockerDocker root is enabled by default. No such problem. See https://stackoverflow.com/questions/11506321/how-to-ping-an-ip-address
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_10s_pleg_relist_latency_quantile_099.md

This alert is related to the Kubernetes Kubelet, which is the primary node agent responsible for ensuring containers run in a Pod. The alert specifically relates to the Pod Lifecycle Event Generator (PLEG) module, which is responsible for adjusting the container runtime state and maintaining the Pod's cache. When there is a significant increase in the relisting time for PLEG, you'll receive a `kubelet10splegrelistlatencyquantile099` alert. Follow the steps below to troubleshoot this alert: Check the container runtime health status If you are using Docker as the container runtime, run the following command: ``` sudo docker info ``` Check for any reported errors or issues. If you are using a different container runtime like containerd or CRI-O, refer to the respective documentation for health check commands. Check Kubelet logs for any errors. You can do this by running the following command: ``` sudo journalctl -u kubelet -n 1000 ``` Look for any relevant error messages or warnings in the output. Validate that the node is not overloaded with too many Pods. Run the following commands: ``` kubectl get nodes kubectl describe node <node_name> ``` Adjust the max number of Pods per node if needed, by editing the Kubelet configuration file `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`, adding the `--max-pods=<NUMBER>` flag, and restarting Kubelet: ``` sudo systemctl daemon-reload sudo systemctl restart kubelet ``` Check for issues related to the underlying storage or network. Inspect the Node's storage and ensure there are no I/O limitations or bottlenecks causing the increased latency. Also, check for network-related issues that could affect the communication between the Kubelet and the container runtime. Verify the performance and health of the Kubernetes API server. High workload on the API server could affect the Kubelet's ability to communicate and process Pod updates. Check the API server logs and metrics to find any performance bottlenecks or errors.
Project: Vector (Observability and Analysis / Observability)
File: demo_logs.md

title: Demo Logs description: Generate fake log events, which can be useful for testing and demos component_kind: source layout: component tags: ["demo", "random", "fake", "component", "source"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Grafana Mimir (Observability and Analysis / Observability)
File: design-patterns-and-conventions.md

Grafana Mimir adopts some design patterns and code conventions that we ask you to follow when contributing to the project. These conventions have been adopted based on experience gained over time and aim to enforce good coding practices and keep a consistent UX (ie. config). Grafana Mimir follows the styleguide and the section of Peter Bourgon's . Do not use global variables When registering a metric: Do not use a global variable for the metric Create and register the metric with `promauto.With(reg)` In any internal Grafana Mimir component, do not register the metric to the default Prometheus registerer, but take the registerer in input (ie. `NewComponent(reg prometheus.Registerer)`) Testing metrics: When writing unit tests, test exported metrics using `testutil.GatherAndCompare()` Naming: Config file options should be lowercase with words `` (underscore) separated (ie. `memcachedclient`) CLI flags should be lowercase with words `-` (dash) separated (ie. `memcached-client`) When adding a new config option, look if a similar one already exists within the and keep the same naming (ie. `addresses` for a list of network endpoints) Documentation: A CLI flag mentioned in the documentation or changelog should be always prefixed with a single `-` (dash)
Project: Checkmk (Observability and Analysis / Observability)
File: 16604.md

key | value | date | 2024-03-27T17:14:30+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The `requestCount` metric for tomcat servers was calculated by the plugin to obtain the number of requests per second; but the value obtained by the special agent is already in that format. It is therefore sufficient to monitor the value without further processing.
Project: Checkmk (Observability and Analysis / Observability)
File: 16484.md

key | value | date | 2024-03-08T07:50:30+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes When creating a combined graph with an empty time filter (e.g. Last service check), the creation of the combined graph would crash. This behavior is not consistent with the view filtering behavior, where the filter is not applied if it is empty. Now the filter is not applied to combined graphs either.
Project: Elastic APM (Observability and Analysis / Observability)
File: pull_request_template.md

<!-- Thanks for sending a pull request! If this is your first contribution, please review and sign our contributor agreement - https://www.elastic.co/contributor-agreement. Guidelines: Prefer small PRs, and split changes into multiple logical commits where they must be delivered in a single PR. If the PR is incomplete and not yet ready for review, open it as a Draft. Once the PR is marked ready for review it is expected to pass all tests and linting, and you should not force-push any changes. See also https://github.com/elastic/apm-server/blob/main/CONTRIBUTING.md for more tips on contributing. --> <!-- Describe your change in the title and description, and provide a motivation for the change and rationale for the approach taken. --> <!-- Delete irrelevant items. The changelog should only be updated for user-facing changes. Once the PR is ready for review there should be no unticked boxes. --> [ ] Documentation has been updated For functional changes, consider: Is it observable through the addition of either logging or metrics? Is its use being published in telemetry to enable product improvement? Have system tests been added to avoid regression? <!-- Explain how this PR can be tested by the reviewer: commands, dependencies, steps, etc. If it is self-explanatory, delete this section. --> <!-- Reference the related issue(s), and make use of magic keywords where it makes sense https://help.github.com/articles/closing-issues-using-keywords/. -->