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

Open chunks (the chunks where data is current written into) can't fit into PostgreSQL shared buffers. Total size is calculated by summing up all chunk relations and indexes sizes. Database performance will be affected, especially the ingest speed. The effect will be less if you are running PostgreSQL on fast local disk. Increase percentage of PostgreSQL memory allocated to shared buffers. If you have already allocated huge percentage of memory to shared buffers (eg 75%) you should consider increasing database memory. `shared_buffers` can be set through `postgresql.conf`. To make sure that your new setting is applied you can run: `SELECT * FROM pgsettings WHERE name = 'sharedbuffers';`
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: parser.md

title: Syslog-NG parser weight: 200 generated_file: true Default: - Default: - The regular expression patterns that you want to find a match. regexp-parser() supports multiple patterns, and stops the processing at the first successful match. Default: - Insert a prefix before the name part of the parsed name-value pairs to help further processing. Default: - Specify a template of the record fields to match against. Default: - Pattern flags Default: - Pattern flags Default: -
Project: Cortex (Observability and Analysis / Observability)
File: alert-manager-configuration.md

title: "Configuring Notification using Cortex Alertmanager" linkTitle: "Alertmanager configuration" weight: 10 slug: alertmanager-configuration Cortex Alertmanager notification setup follow mostly the syntax of Prometheus Alertmanager since it is based on the same codebase. The following is a description on how to load the configuration setup so that Alertmanager can use for notification when an alert event happened. With the introduction of Cortex 1.8 the storage backend config option shifted to the new pattern . You can find the new configuration Note that when using `-alertmanager.sharding-enabled=true`, the following storage backends are not supported: `local`, `configdb`. When using the new configuration pattern it is important that any of the old configuration pattern flags are unset (`-alertmanager.storage`), as well as `-<prefix>.configs.url`. This is because the old pattern still takes precedence over the new one. The old configuration pattern (`-alertmanager.storage`) is marked as deprecated and will be removed by Cortex version 1.11. However this change doesn't apply to `-alertmanager.storage.path` and `-alertmanager.storage.retention`. Cortex Alertmanager can be uploaded via Cortex or using . Follow the instruction at the `cortextool` link above to download or update to the latest version of the tool. To obtain the full help of how to use `cortextool` for all commands and flags, use `cortextool --help-long`. The following example shows the steps to upload the configuration to Cortex `Alertmanager` using `cortextool`. The following is `amconfig.yml`, an example of a configuration for Cortex `Alertmanager` to send notification via email: ``` global: smtp_smarthost: 'localhost:25' smtp_from: 'alertmanager@example.org' smtpauthusername: 'alertmanager' smtpauthpassword: 'password' route: receiver: send-email receivers: name: send-email email_configs: to: 'someone@localhost' ``` to support receiving Alertmanager notification. In this example, Cortex `Alertmanager` is set to be available via localhost on port 8095 with user/org = 100. To upload the above configuration `.yml` file with `--key` to be your Basic Authentication or API key: ``` cortextool alertmanager load ./amconfig.yml \ --address=http://localhost:8095 \ --id=100 \ --key=<yourKey> ``` If there is no error reported, the upload is successful. To upload the configuration for Cortex `Alertmanager` using Cortex API and curl - see Cortex . ``` cortextool alertmanager get \ --address=http://localhost:8095 \ --id=100 \ --key=<yourKey> ```
Project: Cortex (Observability and Analysis / Observability)
File: pull_request_template.md

<!-- Thanks for sending a pull request! Before submitting: Read our CONTRIBUTING.md guide Rebase your PR if it gets out of sync with master --> What this PR does: Which issue(s) this PR fixes: Fixes #<issue number> Checklist [ ] Tests updated [ ] Documentation added [ ] `CHANGELOG.md` updated - the order of entries should be `[CHANGE]`, `[FEATURE]`, `[ENHANCEMENT]`, `[BUGFIX]`
Project: Checkmk (Observability and Analysis / Observability)
File: 15745.md

key | value | date | 2024-01-18T07:51:01+00:00 version | 2.3.0b1 class | feature edition | cee component | multisite level | 1 compatible | yes Prior to this werk, generating a support diagnostic for deployments with distributed monitoring of multiple Checkmk instances would expose site secrets within the "etc/check_mk/multisite.d/sites.mk" file. All site secrets are now replaced with "redacted" during the generation process of support diagnostics <i>(Setup > Maintenance > Support diagnostics)</i> where <i>Checkmk Configuration files</i> have been selected with at least low sensitivity or the <i>sites.mk</i> file has been selected individually.
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-31-guides-section.md

date: "2020-03-31" title: "A New Guides Section" description: "High quality guides and education for Vector" authors: ["binarylogic"] pr_numbers: [2132] release: "0.9.0" hideonrelease_notes: false badges: type: "new feature" domains: ["website"] Vector is only as good as it's documentation and education. And while we put effort into our , we felt there was an educational aspect missing, so we launched a new . This section is meant to house high-quality guides that will be maintained and updated continuously. To kick this new section off we've added the following guides: {{< jump "/docs/setup/quickstart" >}} {{< jump "/guides/advanced/custom-aggregations-with-lua" >}} {{< jump "/guides/advanced/parsing-csv-logs-with-lua" >}}
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: mattermost.md

title: Mattermost weight: 200 generated_file: true Sends logs to Mattermost via webhooks. For details, see . ```yaml spec: mattermost: webhook_url: https://xxx.xx/hooks/xxxxxxxxxxxxxxx channel_id: xxxxxxxxxxxxxxx message_color: "#FFA500" enable_tls: false ``` The path of the CA certificates. The ID of the channel where you want to receive the information. You can set the communication channel if it uses TLS. Default: true The message you want to send. It can be a static message, which you add at this point, or you can receive the Fluentd infos with the %s Color of the message you are sending, in hexadecimal format. Default: #A9A9A9 The title you want to add to the message. Default: fluenttitledefault Incoming Webhook URI (Required for Incoming Webhook mode).
Project: Vector (Observability and Analysis / Observability)
File: 2021-11-12-event-throttle-transform.md

date: "2021-11-18" title: "Event `throttle` transform released" description: "A guide to using the new `throttle` transform" authors: ["barieom"] pr_numbers: [9378] release: "0.18.0" hideonrelease_notes: false badges: type: new feature We've released a new `throttle` transform that provides a user the ability to throttle the throughput of specific event streams. Large spikes in the volume of observability data can have undesirable impacts including increased costs for sink destinations that price based on volume or accidentally overwhelming internally deployed services like Loki. To protect yourself from these effects, we've added a new transform to Vector. The transform enables you to rate limit specific subsets of your event stream to limit load on downstream services or enforce quotas on specific services (identified by fields on the log event). You can also exclude events based on a [VRL condition] to avoid dropping critical logs. To ensure that each bucket's throughput averages out to the `threshold` per `window`, rate limiting spreads load across the configured `window` (configured by `window_secs`). The rate limiter will allow up to threshold number of events through and drop any further events for that particular bucket when the rate limiter is at capacity. A rate limiter is created with a maximum number of cells equal to the `threshold`, with cells replenishing at a rate of `window` divided by `threshold`. For example, a `window` of 60 with a `threshold` of 10 replenishes a cell every 6 seconds and allows a burst of up to 10 events. See the following simple example. Given these incoming log events: ```json [ {"host":"host-1.hostname.com","message":"First message","timestamp":"2020-10-07T12:33:21.223543Z"}, {"host":"host-1.hostname.com","message":"Second message","timestamp":"2020-10-07T12:33:21.223543Z"} ] ``` ...and this configuration... ```toml [transforms.mytransformid] type = "throttle" inputs = [ "my-source-or-transform-id" ] threshold = 1 window_secs = 60 ``` ...only one event will be allowed through: ```json {"host":"host-1.hostname.com","message":"First message","timestamp":"2020-10-07T12:33:21.223543Z"} ``` Due to the threshold of `1` event per 60 seconds. If you any feedback, let us know on our [Discord chat] or [Twitter].
Project: Netdata (Observability and Analysis / Observability)
File: 1m_ipv4_udp_send_buffer_errors.md

The linux kernel allocates buffers to serve the UDP protocol operations. Data is written into sockets that utilize UDP to send data to an another system/subsystem. The Netdata Agent monitors the average number of UDP send buffer errors over the last minute. This alert indicates that the UDP send buffer is full or no kernel memory available. Receiving this alert means that your system is dropping outgoing UDP packets. This alert is triggered in warning state when the number of UDP send buffer errors over the last minute is more than 10. In general, issues with buffers that allocated dynamically are correlated with the kernel memory, you must always be aware of memory pressure events. This can cause buffer errors. Increase the net.core.wmemdefault and net.core.wmemmax values Try to increase them, RedHat suggests the value of 262144 bytes ``` sysctl -w net.core.wmem_default=262144 sysctl -w net.core.wmem_max=262144 ``` Verify the change and test with the same workload that triggered the alarm originally. ``` sysctl net.core.wmemdefault net.core.wmemmax net.core.wmem_default=262144 net.core.wmem_max=262144 ``` If this change works for your system, you could make it permanently. Bump these `net.core.wmemdefault=262144` & `net.core.wmemmax=262144` entries under `/etc/sysctl.conf`. Reload the sysctl settings. ``` sysctl -p ```
Project: Netdata (Observability and Analysis / Observability)
File: getmntinfo.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/getmntinfo.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "getmntinfo" learn_status: "Published" learnrelpath: "Collecting Metrics/FreeBSD" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/hard-drive.svg" width="150"/> Plugin: freebsd.plugin Module: getmntinfo <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect information per mount point. The plugin calls `getmntinfo` function to collect necessary data. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. These metrics show detailss about mount point usages. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | disk.space | avail, used, reservedforroot | GiB | | disk.inodes | avail, used, reservedforroot | inodes | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | disk.space | disk ${label:mount_point} space utilization | | | disk.inodes | disk ${label:mount_point} inode utilization | No action required. The configuration file name for this integration is `netdata.conf`. Configuration for this specific integration is located in the `[plugin:freebsd:getmntinfo]` section within that file. The file format is a modified INI syntax. The general structure is: ```ini [section1] option1 = some value option2 = some other value [section2] option3 = some third value ``` You can edit the configuration file using the `edit-config` script from the Netdata . ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config netdata.conf ``` <details><summary>Config options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | enable new mount points detected at runtime | Cheeck new mount points during runtime. | auto | no | | space usage for all disks | Enable or disable space usage for all disks metric. | auto | no | | inodes usage for all disks | Enable or disable inodes usage for all disks metric. | auto | no | | exclude space metrics on paths | Do not show metrics for listed paths. | /proc/* | no | | exclude space metrics on filesystems | Do not monitor listed filesystems. | autofs procfs subfs devfs none | no | </details> There are no configuration examples.
Project: SkyWalking (Observability and Analysis / Observability)
File: SWIP-4.md

UI could jump to the service dashboard and query service hierarchy from the topology node. For now topology node includes name and ID but without layer, as the service could have multiple layers, the limitation is that it is only works on the current layer which the topology represents: UI could not jump into another layer's dashboard of the service. UI could not query the service hierarchy from the topology node if the node is not in current layer. Here are typical use cases: should have a chance to jump into another layer's dashboard of the service: In the mesh topology, mesh(layer MESH) and mesh-dp(layer MESH_DP) share a similar topology, one node will have two layers. In the mesh topology, agent(layer GENERAL) + virtual database(layer VIRTUAL_DATABASE), the node is in different layers. Both of these two cases have hybrid layer topology. If we could support that, we could have a better x-layer interaction. There is no significant architecture-level change. Add the layers info into topology node: When building the topology node fetch the layers info from the service according to the service id. Return `layers` info in the `Node` when query the topology. No new library is planned to be added to the codebase. About the protocol, there should be no breaking changes, but enhancements only. New field `layers` is going to be added to the `Node` in the query protocol `topology.graphqls`. ```graphql type Node { id: ID! name: String! type: String isReal: Boolean! layers: [String!]! } ``` This proposal doesn't impact the end user in any way of using SkyWalking. The remarkable change will be in the UI topology map, users could jump into the proper layer's service dashboard and query the service hierarchy from the topology node.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: s3.md

title: S3 weight: 200 generated_file: true Sends messages from a local network to a S3 (compatible) server. For more information, see the . Available in Logging operator version 4.4 and later. {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: SyslogNGOutput metadata: name: s3 spec: s3: url: "https://s3-endpoint" bucket: "s3bucket-name" access_key: valueFrom: secretKeyRef: name: s3 key: access-key secret_key: valueFrom: secretKeyRef: name: s3 key: secret-key object_key: "path/to/my-logs/${HOST}" {{</ highlight >}} For available macros like `$PROGRAM` and `$HOST`, see the . The access_key for the S3 server. The bucket name of the S3 server. Set the canned_acl option. Set the chunk size. Default: 5MiB Set the compression level (1-9). Default: 9 Enable or disable compression. Default: false This option enables putting outgoing messages into the disk buffer of the destination to avoid message loss in case of a system failure on the destination side. For details, see the . Default: false Set the number of seconds for flush period. Default: 60 The number of messages that the output queue can store. Set the maximum object size size. Default: 5120GiB Set the maximum number of pending uploads. Default: 32 The object_key for the S3 server. Set objectkeytimestamp Persistname Set the region option. The number of times syslog-ng OSE attempts to send a message to this destination. If syslog-ng OSE could not send a message, it will try again until the number of attempts reaches retries, then drops the message. The secret_key for the S3 server. Set the storage_class option. Template Sets the maximum number of messages sent to the destination per second. Use this output-rate-limiting functionality only when using disk-buffer as well to avoid the risk of losing messages. Specifying 0 or a lower value sets the output limit to unlimited. Default: 0 Set the number of upload threads. Default: 8 The hostname or IP address of the S3 server.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Cortex (Observability and Analysis / Observability)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: abinbev.md

Anheuser-Busch InBev SA/NV, commonly known as AB InBev, is a Belgian multinational drink and brewing company based in Leuven, Belgium. AB InBev has a global functional management office in New York City, and regional headquarters in So Paulo, London, St. Louis, Mexico City, Bremen, Johannesburg and others. After an evaluation period of some Chaos Engineering tools, we chose Litmus because it is a more mature tool that would meet most of our needs. We are in the implementation, configuration, and process definition phase. AB-Inbev's BEES is a huge project that has hundreds of microservices, it has been a great challenge to adapt Litmus in this process, making customizations and counting on the help of the Litmus community to evolve the tool and thus achieve our goal of making it available to the teams. Some points that made us choose Litmus: Based on K8S resources SSO Customization of attacks, attacks in parallel Installation on multiple clusters GitOps
Project: Netdata (Observability and Analysis / Observability)
File: gearman_workers_queued.md

This alert is related to the Gearman application framework. If you receive this alert, it means that the average number of queued jobs in the last 10 minutes is significantly high, indicating that more workers may be needed to maintain an efficient workflow. Gearman is an open-source, distributed job scheduling framework that allows applications to distribute processing tasks among multiple worker machines. It is useful to parallelize tasks and manage workloads between different systems. Check the status of Gearman with the following command: ``` gearadmin --status ``` Analyze the output and identify queues with a high number of jobs: Example output: ``` queue1 50000 10 0 queue2 65000 20 0 ``` In this example, `queue1` and `queue2` have a high number of queued jobs (50,000 and 65,000), with 10 and 20 workers working on them respectively. Increase the number of workers: To increase the number of workers, you may need to start additional worker instances or adjust the configurable number of workers in your Gearman deployment. For instance, if you use a script to start workers, you can update this script and start more instances. Monitor the Gearman metrics: Continue to monitor the metrics for some time to ensure that the additional workers are effectively reducing the number of queued jobs. If necessary, further optimize the Gearman deployment: If the problem persists, you may need to analyze the queues in further detail, such as looking into possible bottlenecks, inefficient operations, or other performance-related factors.
Project: Elastic (Observability and Analysis / Observability)
File: log.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns the logarithm of a value to a base. The input can be any numeric value, the return value is always a double. Logs of zero, negative numbers, and base of one return `null` as well as a warning. ``` ROW base = 2.0, value = 8.0 | EVAL s = LOG(base, value) ```
Project: Graylog (Observability and Analysis / Observability)
File: Tooltip.md

```js const styles = { position: 'relative', display: 'inline-block' }; <div style={{display: "grid", "gridTemplateColumns": "1fr 1fr 1fr 1fr"}}> <div style={{height: "24px"}}> <Tooltip placement="right" className="in" id="tooltip-right" style={styles}> Tooltip right </Tooltip> </div> <div style={{height: "24px"}}> <Tooltip placement="top" className="in" id="tooltip-top" style={styles}> Tooltip top </Tooltip> </div> <div style={{height: "24px"}}> <Tooltip placement="left" className="in" id="tooltip-left" style={styles}> Tooltip left </Tooltip> </div> <div style={{height: "24px"}}> <Tooltip placement="bottom" className="in" id="tooltip-bottom" style={styles}> Tooltip bottom </Tooltip> </div> </div> ``` ```js import { ButtonToolbar, Button } from 'components/bootstrap'; import { OverlayTrigger } from 'components/common'; const TooltipExample = () => { const tooltip = ( <Tooltip id="tooltip"> <strong>Yo!</strong> Check this info. </Tooltip> ); return ( <ButtonToolbar> <OverlayTrigger placement="left" overlay={tooltip}> <Button bsStyle="default">Hover Example Left!</Button> </OverlayTrigger> <OverlayTrigger placement="top" overlay={tooltip}> <Button bsStyle="default">Hover Example Top!</Button> </OverlayTrigger> <OverlayTrigger placement="bottom" overlay={tooltip}> <Button bsStyle="default">Hover Example Bottom!</Button> </OverlayTrigger> <OverlayTrigger placement="right" overlay={tooltip}> <Button bsStyle="default">Hover Example Right!</Button> </OverlayTrigger> </ButtonToolbar> ) }; <TooltipExample /> ```
Project: Fluentd (Observability and Analysis / Observability)
File: SECURITY.md

| Version | Supported | | - | | | 1.17.x | :whitecheckmark: | | 1.16.x | :whitecheckmark: | | <= 1.15.x | :x: | Please post your vulnerability report from the following page: https://github.com/fluent/fluentd/security/advisories