cwielenb/CNCF-Dataset huggingface dataset:
Project: Weave Scope (Observability and Analysis / Observability)
File: building.md

title: Developing and Debugging menu_order: 90 search_type: Documentation The following topics are discussed: * Building Scope from source depends on the latest version of , so please install that before proceeding. The build process is automated using `make`, which builds the UI build container, builds the UI in said container, builds the backend build container, builds the app and probe in said container, and finally pushes the lot into a Docker image called weaveworks/scope. make Then, run the local build via: ./scope launch If needed, install the tools used for managing dependencies, managing releases, and doing coverage analysis via: make deps Scope unit tests for `probe` and `app` components can be run via: make tests Similarly the frontend client tests can be run via: make client-test Note: The tools from `make deps` depend on a local install of . Scope has a collection of built-in debugging tools to aid Scope developers. To get debug information in the logs launch Scope with `--debug`: scope launch --debug docker logs weavescope To have the Scope App or Scope Probe dump their goroutine stacks, run: kill -QUIT $(pgrep -f scope-(app|probe)) docker logs weavescope The Scope Probe is instrumented with various counters and timers. To have it dump those values, run: kill -USR1 $(pgrep -f scope-probe) docker logs weavescope If you run with `--probe.http.listen` enabled, these are exposed as Prometheus metrics instead, via http at `/metrics`. Both the Scope App and the Scope Probe offer . These cover things such as CPU usage and memory consumption: The Scope App enables its HTTP profiling endpoints by default, which are accessible on the same port the Scope UI is served (4040). The Scope Probe doesn't enable its profiling endpoints by default. To enable them, you must launch Scope with `--probe.http.listen addr:port`. For instance, launching Scope with `scope launch --probe.http.listen :4041`, will allow you access the Scope Probe's profiling endpoints on port 4041. Then, you can collect profiles in the usual way. For instance: To collect the memory profile of the Scope App: go tool pprof http://localhost:4040/debug/pprof/heap To collect the CPU profile of the Scope Probe: go tool pprof http://localhost:4041/debug/pprof/profile To collect a blocking profile of the Scope App, make sure you have launched Scope with `--app.block.profile.rate=N` (where `N` is the number of nanoseconds between samples) and then: go tool pprof http://localhost:4040/debug/pprof/block If you don't have `go` installed, you can use a Docker container instead: To collect the memory profile of the Scope App: docker run --net=host -v $PWD:/root/pprof golang go tool pprof http://localhost:4040/debug/pprof/heap To collect the CPU profile of the Scope Probe: docker run --net=host -v $PWD:/root/pprof golang go tool pprof http://localhost:4041/debug/pprof/profile You will find the output profiles in your working directory.
Project: Netdata (Observability and Analysis / Observability)
File: cockroachdb_used_storage_capacity.md

This alert indicates high storage capacity utilization in CockroachDB. The maximum size allocated to the node. When this size is reached, CockroachDB attempts to rebalance data to other nodes with available capacity. When there's no capacity elsewhere, this limit will be exceeded. Also, data may be written to the node faster than the cluster can rebalance it away; in this case, as long as capacity is available elsewhere, CockroachDB will gradually rebalance data down to the store limit. Increase the space available for CockroachDB data If you had previously set a limit, then you can use the option `--store=path<YOUR PATH>,size=<SIZE>` to increase the amount of available space. Make sure to replace the "YOUR PATH" with the actual store path and "SIZE" with the new size you want to set CockroachDB to. Note: If you haven't set a limit on the size, then the entire drive's size will be used. In this case, you will see that the drive is full. Clearing some space or upgrading to a drive with a larger capacity are potential solutions. Inspect the disk usage by tables and indexes CockroachDB provides the `experimentaldiskusage` builtin SQL function that allows you to check the disk usage by tables and indexes within a given database. This can help you identify the main storage consumers in your cluster. To run this command, first connect to your CockroachDB instance with `cockroach sql`, then execute the following query: ```sql SELECT * FROM [SHOW experimentaldiskusage('<database_name>')]; ``` Make sure to replace `<database_name>` with the actual name of the database you want to inspect. This will return a list of tables and indexes with their respective disk usage. Rebalance the cluster data to other nodes with available capacity CockroachDB automatically rebalances data across nodes by default. If the data rebalancing is not happening fast enough, you can try to speed up this process by or by . Purge old, unnecessary data Inspect your data and consider purging old or unnecessary data from the database. Be cautious while performing this operation and double-check the data you intend to remove. Archive old data If the data cannot be purged, consider archiving it in a more compact format or moving it to a separate database or storage system to reduce the storage usage on the affected CockroachDB node.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-1-0.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.1.0 <!-- Auto generated by update changelog github action --> API: Allow creating teams with a user defined identifier. , Alerting: Adds interval and For to alert rule details. , Alerting: Extend PUT rule-group route to write the entire rule group rather than top-level fields only. , Alerting: Use Adaptive Cards in Teams notifications. , Azure Monitor: Add Network Insights Dashboard. , Chore: Improve logging of unrecoverable errors. , Correlations: Add UpdateCorrelation HTTP API. , Dashboard: Reverted the changes of hiding multi-select and all variable in the datasource picker. , Geomap: Add alpha day/night layer. , Geomap: Add measuring tools. , GrafanaUI: Add success state to ClipboardButton. , Heatmap: Replace the heatmap panel with new implementation. , KVStore: Allow empty value in kv_store. , Prometheus: Promote Azure auth flag to configuration. , Reports: Save and update in reports should be transactional. (Enterprise) Reports: Set uid when we don't receive it in the query. (Enterprise) Search: Display only dashboards in General folder of Search Folder View. , Status history/State timeline: Support datalinks. , Transform: Add a limit transform. , Transformations: Add standard deviation and variance reducers. , API: Fix snapshot responses. , Access Control: Fix permission error during dashboard creation flow. , Access Control: Set permissions for Grafana's test data source. , Alerting: Fix migration failure. , BarGauge: Show empty bar when value, minValue and maxValue are all equal. , Dashboard: Fix color of bold and italics text in panel description tooltip. , Loki: Fix passing of query with defaults to code mode. , Loki: Fix producing correct log volume query for query with comments. , Loki: Fix showing of unusable labels field in detected fields. , Reports: Fix inconsistency reports. (Enterprise) Tracing: Fix OpenTelemetry Jaeger context propagation. , Tracing: Fix OpenTelemetry Jaeger context propagation (#53269). , , Alert notifications to Microsoft Teams now use Adaptive Cards instead of Office 365 Connector Cards. Issue Starting at 9.1.0, existing heatmap panels will start using a new implementation. This can be disabled by setting the `useLegacyHeatmapPanel` feature flag to true. It can be tested on a single dashbobard by adding `?feature.useLegacyHeatmapPanel=true` to any dashboard URL. Please report any . The most notable changes are: Significantly improved rendering performance When calculating heatmaps, the buckets are now placed on reasonable borders (1m, 5m, 30s etc) Round cells are no longer supported Issue Plugins: Only pass `rootUrls` field in request when not empty. ,
Project: Vector (Observability and Analysis / Observability)
File: 2021-10-08-0-17-upgrade-guide.md

date: "2021-10-08" title: "0.17 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.17.0" authors: ["jszwedko", "tobz"] pr_numbers: [] release: "0.17.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.17.0 release includes several breaking changes: We cover them below to help you upgrade quickly: We've updated the blackhole sink to print its statistics summary on an interval, rather than after a specific number of events. This provides a consistent reporting experience regardless of the number of events coming into the sink, including when no events are coming in. The configuration field `printamount` has been removed, and replaced with `printinterval_secs`. Additionally, `printintervalsecs` defaults to `1 second`, which has the additional benefit of providing a very basic "events per second" indicator out-of-the-box. We've updated the Datadog Logs sink to conform more tightly to the Datadog Logs API's constraints, one of which is a maximum payload size. The recommendation of that API is to send payloads as close to but not over 5MB in an uncompressed, serialized form. The sink will now always try to send 5MB payloads, consistent with your timeout settings. Users that have previously set `batch.max_bytes` may now safely remove the value. If it is left the setting will have no effect. Previously, Vector used to log all output to stdout, but this made it difficult to use the output of the `console` sink, which also writes to stdout by default. Following some discussion in we decided to modify Vector to, instead, log to stderr so that stdout can be processed separately. If you were previously depending on Vector's logs appearing in stdout, you should now look for them in stderr. Previously, the source had no default `interval`, which meant that if you started Vector without setting an `interval`, the `generator` would output batches of test events as fast as it can. In version 0.17.0, the default for `interval` is now `1.0`, which means that Vector outputs one batch per second. To specify no delay between batches you now need to explicit set `interval` to `0.0`. The `wasm` transform was and has been removed in this release. In its place, we recommend using the `remap` and `lua` transforms. Note, we may revisit adding WASM support to Vector for custom plugins in the future. If you have a use-case, please add it to the . Previously, the had an `eventperline` setting that controlled how events were parsed out of the input data from the executed program. This has been removed and replaced by separate and options that provide more control over the formats that this source accepts. The algorithm underlying the mechanism has been optimized in this release to take into account the variance between request response times. This has come with changes to the configuration as well. The option to control the RTT threshold value, `rttthresholdratio`, has been replaced by the RTT variance calculation. It has been replaced by which can be used to adjust the scale factor applied to this value.
Project: Zipkin (Observability and Analysis / Observability)
File: RELEASE.md

This repo uses semantic versions. Please keep this in mind when choosing version numbers. Verify all dependencies are up-to-date Before you start a release, make sure all dependencies are up-to-date, or are documented why not. Pay special attention to the , which should run clean. Alert others you are releasing There should be no commits made to master while the release is in progress (about 10 minutes). Before you start a release, alert others on so that they don't accidentally merge anything. If they do, and the build fails because of that, you'll have to recreate the release tag described below. Push a git tag The trigger format is `release-MAJOR.MINOR.PATCH`, ex `git tag release-1.18.1 && git push origin release-1.18.1`. Wait for CI The `release-MAJOR.MINOR.PATCH` tag triggers , which creates commits, `MAJOR.MINOR.PATCH` tag, and increments the version (maven-release-plugin). The `MAJOR.MINOR.PATCH` tag triggers , which does the following: Publishes jars to https://oss.sonatype.org/content/repositories/releases Later, the same jars synchronize to Maven Central Publishes Javadoc to https://zipkin.io/brave into a versioned subdirectory Pushes images to Docker registries Notes: https://search.maven.org/ index will take longer than direct links like https://repo1.maven.org/maven2/io/zipkin The release process uses various credentials. If you notice something failing due to unauthorized, look at the notes in . If you receive a '401 unauthorized' failure from OSSRH, it is likely `SONATYPEUSER` or `SONATYPEPASSWORD` entries are invalid, or possibly the user associated with them does not have rights to upload. The least destructive test is to try to publish a snapshot manually. By passing the values CI would use, you can kick off a snapshot from your laptop. This is a good way to validate that your unencrypted credentials are authorized. Here's an example of a snapshot deploy with specified credentials. ```bash $ export GPGTTY=$(tty) && GPGPASSPHRASE=whackamole SONATYPEUSER=adrianmole SONATYPEPASSWORD=ed6f20bde9123bbb2312b221 build-bin/build-bin/maven/maven_deploy ``` If for some reason, you lost access to CI or otherwise cannot get automation to work, bear in mind this is a normal maven project, and can be released accordingly. Note: If , the below will not work. ```bash export GPG_TTY=$(tty) export GPGPASSPHRASE=yourgpg_passphrase export SONATYPEUSER=yoursonatype_account export SONATYPEPASSWORD=yoursonatype_password release_version=xx-version-to-release-xx ./build-bin/maven/mavenrelease release-${releaseversion} git checkout ${release_version} ./build-bin/deploy ./mvnw release:clean git checkout master git reset HEAD --hard ```
Project: Chaos Toolkit (Observability and Analysis / Chaos Engineering)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: pending-review 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: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: syslogng_clusterflow_types.md

title: SyslogNGClusterFlow weight: 200 generated_file: true SyslogNGClusterFlow is the Schema for the syslog-ng clusterflows API SyslogNGClusterFlowSpec is the Kubernetes spec for Flows Output metrics are applied before the log reaches the destination and contain output metadata like: `name,` `namespace` and `scope`. Scope shows whether the output is a local or global one. Available in Logging operator version 4.5 and later. SyslogNGClusterFlowList contains a list of SyslogNGClusterFlow
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-ruler.md

aliases: ../../operators-guide/deploying-grafana-mimir/jsonnet/configuring-ruler/ configuring-ruler/ ../../operators-guide/deploy-grafana-mimir/jsonnet/configure-ruler/ description: Learn how to configure the Grafana Mimir ruler when using Jsonnet. menuTitle: Configure ruler title: Configure the Grafana Mimir ruler with Jsonnet weight: 20 The ruler is an optional component and is therefore not deployed by default when using Jsonnet. For more information about the ruler, see . To enable it, add the following Jsonnet code to the `_config` section: ```jsonnet { _config+:: { ruler_enabled: true, rulerstoragebucket_name: 'ruler-bucket-name', }, } ``` By default, the object storage backend used for the ruler will be the one set by the `$.config.storagebackend` option. If desired, you can override it by setting the `$.config.rulerstorage_backend` option. The `rulerstoragebackend` option must be one of either `local`, `azure`, `gcs`, or `s3`. For more information about the options available for storing ruler state, see . To get started, use the `local` client type for initial testing: ```jsonnet { _config+:: { ruler_enabled: true, rulerstoragebackend: 'local', rulerlocaldirectory: '/path/to/local/directory', }, } ``` If you are using object storage, you must set `rulerstoragebucket_name` to the name of the bucket that you want to use. {{< admonition type="note" >}} If ruler object storage credentials differ from the ones defined in the common section, you need to manually provide them by using additional command line arguments. For more information, refer to . {{< /admonition >}} The ruler has two operational modes: internal and remote. By default, the Jsonnet deploys the ruler by using the internal operational mode. For more information about these modes, see . To enable the remote operational mode, add the following code to the Jsonnet: ```jsonnet { _config+:: {n rulerremoteevaluation_enabled: true, }, } ``` {{< admonition type="note" >}} To support the remote operational mode, the configuration includes three additional Kubernetes Deployments as a separate query path. These are: `ruler-query-frontend` `ruler-query-scheduler` `ruler-querier` {{< /admonition >}} To perform a zero downtime migration from internal to remote rule evaluation, follow these steps: Deploy the following changes to enable remote evaluation in migration mode. Doing so causes the three new and previously listed Kubernetes deployments to start. However, they will not reconfigure the ruler to use them just yet. ```jsonnet { _config+:: { rulerremoteevaluation_enabled: true, rulerremoteevaluationmigrationenabled: true, }, } ``` Check that all of pods for the following deployments have successfully started before moving to the next step: `ruler-query-frontend` `ruler-query-scheduler` `ruler-querier` Reconfigure the ruler pods to perform remote evaluation, by deploying the following changes: ```jsonnet { _config+:: { rulerremoteevaluation_enabled: true, }, } ```
Project: Grafana (Observability and Analysis / Observability)
File: profiling-and-tracing.md

title: How profiling and tracing work together menuTitle: How profiling and tracing work together description: Learn about how profiling and tracing work together. weight: 250 keywords: pyroscope data source continuous profiling tracing {{< docs/shared source="grafana" lookup="datasources/pyroscope-profile-tracing-intro.md" version="<GRAFANA_VERSION>" >}}
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: sumologic_http.md

title: Sumo Logic HTTP weight: 200 generated_file: true More info at https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/55 The Cloud Syslog Cloud Token that you received from the Sumo Logic service while configuring your cloud syslog source. Default: empty This option specifies your Sumo Logic deployment.https://help.sumologic.com/APIs/General-API-Information/Sumo-Logic-Endpoints-by-Deployment-and-Firewall-Security Default: empty Custom HTTP headers to include in the request, for example, headers("HEADER1: header1", "HEADER2: header2"). Default: empty The time to wait in seconds before a dead connection is reestablished. Default: 60 This option sets various options related to TLS encryption, for example, key/certificate files and trusted CA locations. TLS can be used only with tcp-based transport protocols. For details, see https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/73#TOPIC-1829193 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. Default: false Default: - Default: - Default: - Default: - Default: -
Project: Grafana Mimir (Observability and Analysis / Observability)
File: glossary.md

aliases: /operators-guide/reference-glossary/ description: Grafana Mimir glossary terms. menuTitle: Glossary title: Grafana Mimir glossary weight: 130 The terms and definitions that follow relate to Grafana Mimir and GEM. Blocks storage is the Mimir storage engine based on the Prometheus TSDB. Grafana Mimir stores blocks in object stores such as AWS S3, Google Cloud Storage (GCS), Azure blob storage, or OpenStack Object Storage (Swift). For a complete list of supported backends, refer to A chunk is an object containing encoded timestamp-value pairs for one series. Churn is the frequency at which series become idle. A series becomes idle after its no longer exported by the monitored targets. Typically, series become idle after a monitored target process or node gets terminated. Grafana Mimir comprises several components. Each component provides a specific function to the system. For component specific documentation, refer to one of the following topics: Flushing is the operation run by ingesters to offload time series from memory and store them in the long-term storage. Gossip is a protocol by which components coordinate without the need for a centralized . The HA tracker is a feature of the Grafana Mimir distributor. It deduplicates time series received from two or more Prometheus servers that are configured to scrape the same targets. To configure HA tracking, refer to . The hash ring is a distributed data structure used by Grafana Mimir for sharding, replication, and service discovery. Components use a or to share the hash ring data structure. For more information, refer to the . A key-value store is a database that associates keys with values. To understand how Grafana Mimir uses key-value stores, refer to . Memberlist manages cluster membership and member failure detection using . Refer to . Refer to . A sample is a single timestamped value in a time series. Given the series `nodecpuseconds_total{instance="10.0.0.1",mode="system"}` its stream of samples may look like: ``` 11775 @1603812134 11790 @1603812149 11805 @1603812164 11819 @1603812179 11834 @1603812194 ``` A series is a single stream of belonging to the same metric, with the same set of label key-value pairs. Given a single metric `nodecpuseconds_total` you may have multiple series, each one uniquely identified by the combination of metric name and unique label key-value pairs: ``` nodecpuseconds_total{instance="10.0.0.1",mode="system"} nodecpuseconds_total{instance="10.0.0.1",mode="user"} nodecpuseconds_total{instance="10.0.0.2",mode="system"} nodecpuseconds_total{instance="10.0.0.2",mode="user"} ``` A tenant is the owner of a set of series written to and queried from Grafana Mimir. Grafana Mimir isolates series and alerts belonging to different tenants. To understand how Grafana Mimir authenticates tenants, refer to . Refer to . Refer to . The write-ahead Log (WAL) is an append only log stored on disk by ingesters to recover their in-memory state after the process gets restarted. For more information, refer to .
Project: Botkube (Observability and Analysis / Observability)
File: botkube_login.md

title: botkube login Login to a Botkube Cloud ``` botkube login [OPTIONS] [flags] ``` ``` botkube login ``` ``` --cloud-dashboard-url string Botkube Cloud URL (default "https://app.botkube.io") -h, --help help for login --local-server-addr string Address of a local server which is used for the login flow (default "localhost:8085") ``` ``` -v, --verbose int/string[=simple] Prints more verbose output. Allowed values: 0 - disable, 1 - simple, 2 - trace (default 0 - disable) ``` - Botkube CLI