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

sort: 8 weight: 8 title: VMPodScrape menu: docs: parent: "operator-custom-resources" weight: 8 aliases: /operator/resources/vmpodscrape.html The `VMPodScrape` CRD allows to declaratively define how a dynamic set of pods should be monitored. Use label selections to match pods for scraping. This allows an organization to introduce conventions for how metrics should be exposed. Following these conventions new services will be discovered automatically without need to reconfigure. `VMPodScrape` object generates part of configuration with role `pod` having specific labels and ports. It has various options for scraping configuration of target (with basic auth,tls access, by specific port name etc.). A `Pod` is a collection of one or more containers which can expose Prometheus metrics on a number of ports. The `VMPodScrape` object discovers pods and generates the relevant scraping configuration. The `PodMetricsEndpoints` section of the `VMPodScrapeSpec` is used to configure which ports of a pod are going to be scraped for metrics and with which parameters. Both `VMPodScrapes` and discovered targets may belong to any namespace. It is important for cross-namespace monitoring use cases, e.g. for meta-monitoring. Using the `namespaceSelector` of the `VMPodScrapeSpec` one can restrict the namespaces from which `Pods` are discovered from. To discover targets in all namespaces the `namespaceSelector` has to be empty: ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMPodScrape metadata: name: example-pod-scrape spec: namespaceSelector: any: true ``` More information about selectors you can find in . You can see the full actual specification of the `VMPodScrape` resource in the . Also, you can check out the section. The `VMPodScrape` CRD from VictoriaMetrics Operator is a drop-in replacement for the Prometheus `PodMonitor` from prometheus-operator. More details about migration from prometheus-operator you can read in . ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMPodScrape metadata: name: example-pod-scrape spec: podMetricsEndpoints: port: web scheme: http selector: matchLabels: owner: dev ```
Project: Graphite (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: "[BUG]" labels: bug assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Environment (please complete the following information): OS flavor: [e.g. Ubuntu, CentOS, Debian etc] Graphite-web version [e.g. 1.1.2, 1.0.1, etc] Django/Python version [e.g. 1.11/2.7, 2.1/3.8 etc] Setup type [e.g. pip, from sources, from OS packages etc] Additional context Add any other context about the problem here.
Project: Vector (Observability and Analysis / Observability)
File: loki.md

title: Loki description: Deliver log event data to the aggregation system component_kind: sink layout: component tags: ["loki", "grafana", "component", "sink", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Netdata (Observability and Analysis / Observability)
File: vsphere_outbound_packets_errors_ratio.md

This alert is triggered when the ratio of outbound errors for the network interface of a virtual machine in vSphere is greater than 1 over the last 10 minutes. Network outbound errors can include dropped, discarded, or errored packets that couldn't be transmitted by the network interface. Outbound packet errors occur when a network interface is unable to transmit packets due to issues like network congestion, hardware problems, or misconfigurations. A high number of outbound packet errors can indicate problems in the network and affect the performance of the virtual machine, resulting in poor application responsiveness and reduced bandwidth. Verify the virtual machine's network configuration. Check virtual machine settings in vSphere to ensure the correct network adapters are assigned and configured properly. Check the virtual machine's guest operating system network configuration for possible errors or misconfigurations. Monitor vSphere network performance counters. Review the network performance counters in vSphere to identify issues or bottlenecks that might be causing the outbound packet errors. Check the physical network. Verify the physical network connections to the virtual machine, including cabling, switches, and routers. Inspect the network hardware to ensure proper functioning and identify faulty hardware. Evaluate network congestion. High network traffic can cause congestion, leading to increased outbound packet errors. Evaluate the network's current usage and identify potential bottlenecks. Review vSphere network policies. Check the network policies applied to the virtual machine, such as rate limiting or other traffic shaping policies, that may be causing the increased rate of outbound packet errors. Examine applications and services. Review the applications and services running on the virtual machine to determine if any of them are generating excessive or abnormal network traffic, resulting in outbound packet errors.
Project: Elastic (Observability and Analysis / Observability)
File: mv_median.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts a multivalued field into a single valued field containing the median value. ``` ROW a=[3, 5, 1] | EVAL mediana = MVMEDIAN(a) ```
Project: Grafana (Observability and Analysis / Observability)
File: set-up-environment.md

labels: products: enterprise oss title: Set up Environment Before you can get started building plugins, you need to set up your environment for plugin development. To discover plugins, Grafana scans a plugin directory, the location of which depends on your operating system. Create a directory called `grafana-plugins` in your preferred workspace. Find the `plugins` property in the Grafana configuration file and set the `plugins` property to the path of your `grafana-plugins` directory. Refer to the for more information. ```ini [paths] plugins = "/path/to/grafana-plugins" ``` Restart Grafana if it's already running, to load the new configuration. If you don't want to install Grafana on your local machine, you can use . To set up Grafana for plugin development using Docker, run the following command: ``` docker run -d -p 3000:3000 -v "$(pwd)"/grafana-plugins:/var/lib/grafana/plugins --name=grafana grafana/grafana:7.0.0 ``` Since Grafana only loads plugins on start-up, you need to restart the container whenever you add or remove a plugin. ``` docker restart grafana ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16476.md

key | value | date | 2024-03-14T10:03:01+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes This werk adds the following labels: For the host with the Nutanix special agent: cmk/nutanix/object:control_plane For Nutanix hosts: cmk/nutanix/object:node cmk/os_platform:nutanix cmk/os_name:Nutanix AHV For Nutanix VMs: cmk/nutanix/object:vm
Project: Tracetest (Observability and Analysis / Observability)
File: README.md

In this folder we have the End-to-end tests done on the CLI to guarantee that the CLI is working fine. The main idea is to test every CLI command against the Tracetest server with different data stores and different operating

| Linux | Windows | MacOS | | | - | | | :whitecheckmark: | :soon: | :soon: | | Jaeger | Tempo | OpenSearch | SignalFx | OTLP | ElasticAPM | New Relic | Lightstep | Datadog | AWS X-Ray | Honeycomb | Dynatrace | | | | - | -- | | - | | | - | | | | | :whitecheckmark: | :soon: | :soon: | :soon: | :soon: | :soon: | :soon: | :soon: | :soon: | :soon: | :soon: | :soon: | | CLI Command | Test scenarios | | -- | - | | `version` | | | `help` | | | `--help`, `-h` | | | `--config` | All scenarios | | CLI Command | Test scenarios | | | -- | | `run test -f | | `run test -f | | `run test -f | | `run testsuite -f | | `run testsuite -f [testsuite-definition] --vars [variableset-id]` | | | `run testsuite -f [testsuite-definition] --vars [variableset-definition]` | | | CLI Command | Test scenarios | | -- | -- | | `apply config -f | | `delete config --id current` | | | `get config --id current --output pretty` | , , | | `get config --id current --output json` | | | `get config --id current --output yaml` | | | `list config --output pretty` | | | `list config --output json` | | | `list config --output yaml` | | | CLI Command | Test scenarios | | -- | -- | | `apply datastore -f | | `delete datastore --id current` | | | `get datastore --id current --output pretty` | , , | | `get datastore --id current --output json` | | | `get datastore --id current --output yaml` | | | `list datastore --output pretty` | | | `list datastore --output json` | | | `list datastore --output yaml` | | | CLI Command | Test scenarios | | - | -- | | `apply demo -f | | `apply demo -f | | `delete demo --id | | `delete demo --id | | `get demo --id , | | `get demo --id | | `get demo --id | | `get demo --id | | `list demo --output pretty` | | | `list demo --output json` | | | `list demo --output yaml` | | | `list demo --skip 1 --take 1` | | | `list demo --sortBy name --sortDirection asc` | | | CLI Command | Test scenarios | | -- | -- | | `apply variableset -f | | `apply variableset -f | | `delete variableset --id | | `delete variableset --id | | `get variableset --id , | | `get variableset --id | | `get variableset --id | | `get variableset --id | | `list variableset --output pretty` | | | `list variableset --output json` | | | `list variableset --output yaml` | | | `list variableset --skip 1 --take 2` | | | `list variableset --sortBy name --sortDirection asc` | | | CLI Command | Test scenarios | | | -- | | `apply pollingprofile -f | | `delete pollingprofile --id current` | | | `get pollingprofile --id current --output pretty` | , , | | `get pollingprofile --id current --output json` | | | `get pollingprofile --id current --output yaml` | | | `list pollingprofile --output pretty` | | | `list pollingprofile --output json` | | | `list pollingprofile --output yaml` | | | CLI Command | Test scenarios | | | -- | | `apply testrunner -f | | `delete testrunner --id current` | | | `get testrunner --id
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-nodata_update.md

category: NoData apiurl: '/api/v1/nodata/' title: "Update Nodata" type: 'PUT' sample_doc: 'nodata.html' layout: default Required ```{ "tags": "", "step": 60, "obj_type": "host", "obj": "docker-agent", "mock": -2, "metric": "test.metric", "id": 4, "dstype": "GAUGE" }``` ```Status: 200``` ```{ "id": 0, "name": "", "obj": "docker-agent", "obj_type": "host", "metric": "test.metric", "tags": "", "dstype": "GAUGE", "step": 60, "mock": -2, "creator": "" }```
Project: Graylog (Observability and Analysis / Observability)
File: TypeAheadDataFilter.md

```js import createReactClass from 'create-react-class'; const lodash = require('lodash'); const TypeAheadDataFilterExample = createReactClass({ getInitialState() { const list = [ { id: '1', title: 'One', description: 'First number', tags: ['one', 'number'] }, { id: '2', title: 'Two', description: 'Second number', tags: ['two', 'number'] }, { id: '3', title: 'Three', description: 'Third number', tags: ['three', 'number'] }, { id: '4', title: 'Four', description: 'Fourth number', tags: ['four', 'number'] }, { id: '5', title: 'A', description: 'First letter', tags: ['a', 'letter'] }, ]; return { list: list, filteredList: list, }; }, onDataFiltered(filteredList) { this.setState({ filteredList: filteredList }); }, render() { const { list, filteredList } = this.state; const suggestions = lodash.uniq(lodash.flatten(list.map((item) => item.tags))); return ( <div> <TypeAheadDataFilter id="awesome-filter" label="Filter list" data={list} displayKey="title" filterBy="tag" filterSuggestions={suggestions} searchInKeys={['title', 'description']} onDataFiltered={this.onDataFiltered} /> <div> <dl> {filteredList.map((item) => [ <dt key={`${item.id}-title`}>{item.title}</dt>, <dd key={`${item.id}-desc`}>{item.description}</dd>, ])} </dl> </div> </div> ); }, }); <TypeAheadDataFilterExample /> ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-05-20-add-bearer-auth-strategy.md

date: "2020-07-13" title: "Now supporting the bearer auth strategy" description: "Vector can now bear authentication tokens for relevant components." authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2607] release: "0.10.0" badges: type: "enhancement" domains: ["sinks"] sinks: ["http"] The light reading material of taught us all about how bearer auth works, right? You glazed over it? Fine. We read it (and implemented it!) for you. Now you can have Vector use bearer tokens with your favorite (and not so favorite) services. Just drop your token in, and you're done. ```diff title="vector.toml" [sinks.example] type = "http" auth.strategy = "bearer" auth.token = "B14CK-L1V35-M4TT4R" ``` Reminder: If you're building a you may wish to use environment variables! ```diff title="vector.toml" [sinks.example] type = "http" auth.strategy = "bearer" auth.token = "${VECTORSINKSHTTPexampleAUTH_TOKEN}" ``` for more information.
Project: Netdata (Observability and Analysis / Observability)
File: systems.md

<!-- title: "Install on specific environments" description: "Netdata can be installed as a DEB/RPM package, a static binary, a docker container or from source" customediturl: https://github.com/netdata/netdata/edit/master/packaging/installer/methods/systems.md sidebar_label: "Install on specific environments" learn_status: "Published" learnrelpath: "Installation/Install on specific environments" --> This category contains specific instructions for some popular environments. If you have a standard environment that is not yet listed here, just use the If your environment is somewhat old or unusual, check our .
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: node_agent_types.md

title: NodeAgent weight: 200 generated_file: true NodeAgent NodeAgentSpec InlineNodeAgent NodeAgentStatus NodeAgentList InlineNodeAgent @deprecated, replaced by NodeAgent InlineNodeAgent unique name. Set the coroutines stack size in bytes. The value must be greater than the page size of the running system. Don't set too small value (say 4096), or coroutine threads can overrun the stack buffer. Do not change the default value of this parameter unless you know what you are doing. (default: 24576) Default: 24576 Set the flush time in seconds.nanoseconds. The engine loop uses a Flush timeout to define when is required to flush the records ingested by input plugins through the defined output plugins. (default: 1) Default: 1 Set the grace time in seconds as Integer value. The engine loop uses a Grace timeout to define wait time on exit (default: 5) Default: 5 Default: true Set the logging verbosity level. Allowed values are: error, warn, info, debug and trace. Values are accumulative, e.g: if 'debug' is set, it will include error, warning, info and debug. Note that trace mode is only available if Fluent Bit was built with the WITH_TRACE option enabled. (default: info) Default: info
Project: Grafana (Observability and Analysis / Observability)
File: contribute.md

keywords: grafana documentation developers resources labels: products: enterprise oss title: Contribute to Grafana weight: 300 This page lists resources for developers who want to contribute to the Grafana software ecosystem or build plugins for Grafana. These resources are useful for all developers. : Start here to learn how you can contribute your skills to make Grafana even better. : A guide to help you get started developing Grafana software, includes instructions for how to configure Grafana for development. : A guide to help you contribute to Grafana documentation, includes links to beginner-friendly issues. : These guides explain Grafanas background architecture. : A guide for new contributors about how to create your first Grafana pull request. allow you to interact programmatically with the Grafana backend. Our outline Grafana style for frontend, backend, documentation, and more, including best practices. Please read through them before you start editing or coding! explains how we want to write Go code in the future. applies to all documentation created for Grafana products. provides guidance for Grafana e2e tests. provides rules and guidance on developing in React for Grafana. explains how Grafana handles Redux boilerplate code. expands on styling React components with Emotion. explains how to use themes and ThemeContext in Grafana code.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: using-go-module.md

sidebar_position: 10 description: Use the module in your GO application with nothing to install. ```bash go get github.com/thomaspoignant/go-feature-flag ``` Create a new `YAML` file containing your first flag configuration. ```yaml title="flag-config.yaml" test-flag: variations: my-new-feature: true my-old-feature: false defaultRule: percentage: my-new-feature: 20 my-old-feature: 80 ``` This flag split the usage of this flag, 20% will use the variation `my-new-feature` and 80% the variation `my-old-feature`. First, you need to initialize the `ffclient` with the location of your backend file. ```go linenums="1" err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &fileretriever.Retriever{ Path: "flag-config.yaml", }, }) defer ffclient.Close() ``` *This example will load a file from your local computer and will refresh the flags every 3 seconds (if you omit the PollingInterval, the default value is 60 seconds).* :::tip This is a basic configuration to test locally, in production it is better to use a remote place to store your feature flag configuration file. Look at the list of available options in the . ::: Now you can evaluate your flags anywhere in your code. ```go linenums="1" user := ffuser.NewUser("user-unique-key") hasFlag, _ := ffclient.BoolVariation("test-flag", user, false) if hasFlag { // flag "test-flag" is true for the user } else { // flag "test-flag" is false for the user } ``` You can find more examples in the directory.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: index.md

title: "Pyroscope deployment modes" menuTitle: "Deployment modes" description: "You can deploy Pyroscope in either monolithic mode or microservices mode." weight: 20 You can deploy Pyroscope in one of two modes: Monolithic mode: In this mode all components run in a single process and is meant to be used when you only need one pyroscope instance as multiple instances will not share information with each other Microservices mode: In this mode in this mode as you scale out the number of instances, they will share a singular backend for storage and querying The deployment mode is determined by the `-target` parameter, which you can set via CLI flag or YAML configuration. The monolithic mode runs all required components in a single process and is the default mode of operation, which you can set by specifying `-target=all`. Monolithic mode is the simplest way to deploy Pyroscope and is useful if you want to get started quickly or want to work with Pyroscope in a development environment. To see the list of components that run when `-target` is set to `all`, run Pyroscope with the `-modules` flag: ```bash ./pyroscope -modules ``` <!-- Monolithic mode can be horizontally scaled out by deploying multiple Pyroscope binaries with `-target=all`. This approach provides high-availability and increased scale without the configuration complexity of the full . --> In microservices mode, components are deployed in distinct processes. Scaling is per component, which allows for greater flexibility in scaling and more granular failure domains. Microservices mode is the preferred method for a production deployment, but it is also the most complex. In microservices mode, each Pyroscope process is invoked with its `-target` parameter set to a specific Pyroscope component (for example, `-target=ingester` or `-target=distributor`). To get a working Pyroscope instance, you must deploy every required component. For more information about each of the Pyroscope components, refer to . If you are interested in deploying Pyroscope in microservices mode, we recommend that you use .
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.14.md

Bump asm from 9.5 to 9.6 () Bump netty from 4.1.97.Final to 4.1.99.Final () Bump `netty` from 4.1.99.Final to 4.1.100.Final () Bump `netty` from 4.1.100.Final to 4.1.101.Final () Bump `org.apache.zookeeper:zookeper` from 3.8.0 to 3.8.3 () Bump `org.bouncycastle:bc-fips` from 1.0.2.3 to 1.0.2.4 () Bump `org.apache.avro:avro` from 1.10.2 to 1.11.3 () Bump `jetty` from 9.4.51.v20230217 to 9.4.52.v20230823 () Bump `io.projectreactor:reactor-core` from 3.4.23 to 3.4.34 and reactor-netty from 1.0.24 to 1.0.39 () Bump `logback-core` and `logback-classic` to 1.2.13 () Bumps `jetty` version from 9.4.52.v20230823 to 9.4.53.v20231009 () Use iterative approach to evaluate Regex.simpleMatch () Improve compressed request handling ()
Project: Elastic (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for your interest in and contributing to Elasticsearch! There are a few simple things to check before submitting your pull request that can help with the review process. You should delete these items from your submission, but they are here to help bring them to your attention. --> Have you signed the ? Have you followed the ? If submitting code, have you built your formula locally prior to submission with `gradle check`? If submitting code, is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed. If submitting code, have you checked that your submission is for an ? If you are submitting this code for a class then read our for that.
Project: Checkmk (Observability and Analysis / Observability)
File: 14943.md

key | value | date | 2024-01-02T16:50:40+00:00 version | 2.3.0b1 class | fix edition | cee component | agents level | 1 compatible | yes Up to now, when using the agent updater CLI, you would have to use the `--password` (or `-P`) parameter to specify the password for a human user and the `--secret` (or `-S`) parameter to specify the secret for an automation user. This starts to be confusing with the interactive mode: in that case the program assumes that you are using a human user and will fail if the credentials that you enter are valid credentials for an automation user. On top of that, the error message is completely misleading. With this commit, we are changing the behavior of the agent updater so that an automation user credentials will work even if the secret is specified with the `--password` (or `-P`) param. This way the end user don't have to care about which param name is the right one to use: they can just specify the password, or the secret, with the `--password` param and it will work. This also allows the interactive mode to work with an automation user. This change is backward compatible, meaning that everything that used to work up until now, will keep working even after this.