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

Install libpcap and wget ```shell yum install libpcap wget ``` Note: The default libpcap with TPACKETV3 enabled has some performance issue. If performance is critical, you can remove libpcap and reinstall libpcap-1.8.1-6.fc27.x8664.rpm or newer version which drops the TPACKET_V3 patch: http://rpm.pbone.net/index.php3/stat/22/idpl/50238989/com/changelog.html Download and install the RPM package. Find the latest package from . ```shell wget https://github.com/Netis/packet-agent/releases/download/v0.3.6/netis-packet-agent-0.3.6.el6.x86_64.rpm rpm -ivh netis-packet-agent-0.3.6.el6.x86_64.rpm ``` Install libpcap and wget ```bash sudo apt-get install libpcap-dev wget ``` Download and install the DEB package. Find the latest package from . ```bash wget https://github.com/Netis/packet-agent/releases/download/v0.3.6/netis-packet-agent-0.3.6_amd64.deb sudo dpkg -i netis-packet-agent-0.3.6_amd64.deb ``` If libpcap.so.1 not found when running pktminerg, create softlink for libpcap.so.1 in suitable directory. ```bash whereis libpcap.so cd /path/to/libpcap.so ln -s libpcap.so.x.y.z libpcap.so.1 ``` Install libpcap and wget ```shell yum install libpcap wget ``` Download and install the RPM package. Find the latest package from . ```shell wget https://github.com/Netis/packet-agent/releases/download/v0.3.6/netis-packet-agent-0.3.6.el6.x86_64.rpm rpm -ivh netis-packet-agent-0.3.6.el6.x86_64.rpm ``` Download and Install of latest version. Download and Install . Download and ZIP package. Find the latest package from . Extract pktminerg and other utilities from zip, and run it in cmd in Administrator Mode. Note: On Windows platform, you must use NIC's NT Device Name with format "\Device\NPF_{UUID}" as interface param. You can get it with following command: ``` C:\> getmac /fo csv /v "Connection Name","Network Adapter","Physical Address","Transport Name" "Ethernet","Intel(R) Ethernet Connection (4) I219-V","8C-16-45-6B-53-B5","\Device\Tcpip_{4C25EA92-09DF-4FD3-A8B3-1B68E57443E2}" ``` Take last field(Transport Name) and replace "Tcpip" with "NPF" as follow, then you can get interface param of Windows. ``` \Device\NPF_{4C25EA92-09DF-4FD3-A8B3-1B68E57443E2} ``` Use example: ``` C:\> pktminerg -i \Device\NPF_{4C25EA92-09DF-4FD3-A8B3-1B68E57443E2} -r 172.24.103.201 C:\> gredump -i \Device\NPF_{4C25EA92-09DF-4FD3-A8B3-1B68E57443E2} -o capture.pcap ```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: ifood.md

is a Brazilian online food ordering and food delivery platform. It operates mainly in Brazil and Mexico, after it merged its businesses in Argentina and Colombia with rival PedidosYa. We have been using Litmus 2.X at iFood for a couple of months, replacing chaostoolkit as it provides a wider range of experiments out-of-the-box. We've started using it to validate the fallback mechanisms of critical services monthly. Right now, we are expanding its usage to go further and inject failures to drop access to databases, redis, Kafka and AWS services and learn from it and take some countermeasures to improve the critical services. I hope Litmus to become the de-facto tool to implement Chaos Engineering in a simple manner.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_mutatingWebhookConfiguration.KubeMutatingWebhookConfiguration.md

title: "Interface: KubeMutatingWebhookConfiguration" linkTitle: "KubeMutatingWebhookConfiguration" slug: "libk8smutatingWebhookConfiguration.KubeMutatingWebhookConfiguration" .KubeMutatingWebhookConfiguration `KubeMutatingWebhookConfiguration` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ webhooks: { `admissionReviewVersions`: `string` ; `failurePolicy?`: `string` ; `matchPolicy?`: `string` ; `name`: `string` ; `namespaceSelector?`: { `matchExpressions`: `undefined` \| { `key`: `string` ; `operator`: `string` ; `values`: `string`[] ; `sideEffects?`: `string` ; `timeoutSeconds?`: `number` }[]
Project: Vector (Observability and Analysis / Observability)
File: log.md

title: Log events weight: 1 tags: ["logs", "events", "schema"] {{< svg "img/data-model-log.svg" >}} Here's an example representation of a log event (as JSON): ```json { "log": { "custom": "field", "host": "my.host.com", "message": "Hello world", "timestamp": "2020-11-01T21:15:47+00:00" } } ``` {{< config/log-schema >}} Vector is schema-neutral and doesn't require any specific schema. This ensures that Vector can work with a variety of schemas, supporting legacy schemas as well as future schemas. Strings are UTF-8 compatible and are only bounded by the available system memory. Integers are signed integers up to 64 bits. Floats are 64-bit floats. Booleans represent binary true/false values. Timestamps are represented as stored as UTC. There are cases where Vector interacts with formats that don't have a formal timestamp definition, such as JSON. In these cases, Vector ingests the timestamp in its primitive form (string or integer). You can then coerce the field into a timestamp using a `remap` transform with the `parse_timestamp` VRL function. If Vector receives a timestamp that doesn't contain timezone information, it assumes that the timestamp is in local time and converts the timestamp to UTC from the local time. For compatibility with JSON log events, Vector also supports `null` values. Maps are associative arrays mapping string fields to values of any type. Array fields are sequences of values of any type.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-3-5.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.3.5 <!-- Auto generated by update changelog github action --> Alerting: Improve Prometheus Alert Rule error message. , Alerting: Fix alarm message formatting in Dingding. , AzureMonitor: Fix unit translation for MilliSeconds. , Instrumentation: Fix bug with invalid handler label value for HTTP request metrics. , Prometheus: Fixes problem where changing display name in Field tab had no effect. , Tracing: Fixed issue showing more than 300 spans. ,
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-profile-export.md

When visualization doesn't work well on the official UI, users may submit issue reports. This tool helps users package the original profile data to assist the community in locating the issues in the users' cases. NOTE: This report includes the class name, method name, line number, etc. Before making your submission, please make sure that the security of your system wouldn't be compromised. Set the storage in the `tools/profile-exporter/application.yml` file based on your use case. Prepare the data Profile task ID: Profile task ID Trace ID: Trace ID of the profile error Export dir: Directory exported by the data Enter the Skywalking root path Execute shell command ```bash bash tools/profile-exporter/profile_exporter.sh --taskid={profileTaskId} --traceid={traceId} {exportDir} ``` The file `{traceId}.tar.gz` will be generated after executing shell. `basic.yml`: Contains the complete information of the profiled segments in the trace. `snapshot.data`: All monitored thread snapshot data in the current segment. Provide exported data generated from this tool. Provide the operation name and the mode of analysis (including/excluding child span) for the span. Issue description. (It would be great if you could provide UI screenshots.)
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: google-cloud.md

title: Deploying Flagsmith on Google Cloud sidebar_label: Google Cloud sidebar_position: 75 We recommend running Flagsmith on Google Cloud Platform using the following services: for the application server for the database Unless you have specific requirements, we recommend running the . It's best to study our in order to set up the base environment variables. Further environment variables are . Run a single Cloud Run service with at least two container instances running for failover. For more info on sizing, see our . We recommend running with at least to avoid cold starts particularly in order to serve low-latency requests to the SDKs. If you are using health-checks, make sure to use `/health` as the health-check endpoint for both the API and the Front End. We support Postgres versions `11+`. Our SaaS platform runs in production on PostgreSQL version `11`. When starting for the first time, the application will create that database schema automatically. Schema upgrades will also happen seamlessly during application server upgrades.
Project: Checkmk (Observability and Analysis / Observability)
File: 16169.md

key | value | date | 2024-01-05T14:04:50+00:00 version | 2.3.0b1 class | fix edition | cre component | notifications level | 1 compatible | yes Previously, Opsgenie notification wouldn't acknowledge notifications if host or service state went back to OK in the meantime.
Project: M3 (Observability and Analysis / Observability)
File: remote.md

title: "API" weight: 1 The M3 Coordinator implements the Prometheus Remote Read and Write HTTP endpoints, they also can be used however as general purpose metrics write and read APIs. Any metrics that are written to the remote write API can be queried using PromQL through the query APIs as well as being able to be read back by the Prometheus Remote Read endpoint. Write a Prometheus Remote write query to M3. `/api/v1/prom/remote/write` `POST` None. {{% fileinclude file="headersoptionalreadwriteall.md" %}} {{% fileinclude file="headersoptionalwrite_all.md" %}} Binary Prometheus . Refer for an up to date list of remote tuning parameters. There isn't a straightforward way to Snappy compress and marshal a Prometheus WriteRequest protobuf message using just shell, so this example uses a specific command line utility instead. This sample call is made using `promremotecli` which is a command line tool that uses a to Prometheus Remote endpoints. For more information visit the . There is also a that can be used to make requests to the endpoint. Each `-t` parameter specifies a label (dimension) to add to the metric. The `-h` parameter can be used as many times as necessary to add headers to the outgoing request in the form of "Header-Name: HeaderValue". Here is an example of writing the datapoint at the current unix timestamp with value 123.456: <!-- Note: keep this example similar to the one found in query API documentation for consistency/ease of readers. --> ```shell docker run -it --rm \ quay.io/m3db/prometheusremoteclient_golang:latest \ -u http://host.docker.internal:7201/api/v1/prom/remote/write \ -t name:httprequeststotal \ -t code:200 \ -t handler:graph \ -t method:get \ -d $(date +"%s"),123.456 promremotecli_log 2019/06/25 04:13:56 writing datapoint [2019-06-25 04:13:55 +0000 UTC 123.456] promremoteclilog 2019/06/25 04:13:56 labelled [[name httprequests_total] [code 200] [handler graph] [method get]] promremotecli_log 2019/06/25 04:13:56 writing to http://host.docker.internal:7201/api/v1/prom/remote/write {"success":true,"statusCode":200} promremotecli_log 2019/06/25 04:13:56 write success ``` For more details on querying data in PromQL that was written using this endpoint, see the . Read Prometheus metrics from M3. `/api/v1/prom/remote/read` `POST` None. {{% fileinclude file="headersoptionalreadwriteall.md" %}} {{% fileinclude file="headersoptionalread_all.md" %}} Binary Prometheus .
Project: Grafana Mimir (Observability and Analysis / Observability)
File: about-dns-service-discovery.md

aliases: ../configuring/about-dns-service-discovery/ description: DNS service discovery finds addresses of backend services to which Grafana Mimir connects. menuTitle: DNS service discovery title: About Grafana Mimir DNS service discovery weight: 20 Some clients in Grafana Mimir support service discovery via DNS to locate the addresses of backend servers to connect to. The following clients support service discovery via DNS: - `-blocks-storage.bucket-store.chunks-cache.memcached.addresses` `-blocks-storage.bucket-store.index-cache.memcached.addresses` `-blocks-storage.bucket-store.metadata-cache.memcached.addresses` `-query-frontend.results-cache.memcached.addresses` - `-memberlist.join` - `-ruler.alertmanager-url` DNS service discovery supports different discovery modes. You select a discovery mode by adding one of the following supported prefixes to the address: `dns+`<br /> The domain name after the prefix is looked up as an A/AAAA query. For example: `dns+memcached.local:11211`. `dnssrv+`<br /> The domain name after the prefix is looked up as a SRV query, and then each SRV record is resolved as an A/AAAA record. For example: `dnssrv+memcached.tcp.memcached.namespace.svc.cluster.local`. `dnssrvnoa+`<br /> The domain name after the prefix is looked up as a SRV query, with no A/AAAA lookup made after that. For example: `dnssrvnoa+memcached.tcp.memcached.namespace.svc.cluster.local`. The Alertmanager URL must also contain the scheme. For example: `dns+http://alermanager.local:8080`. If no prefix is provided, the provided IP or hostname is used without pre-resolving it.
Project: Weave Scope (Observability and Analysis / Observability)
File: how-it-works.md

title: Understanding Weave Scope menu_order: 70 search_type: Documentation The following topics are discussed: Weave Scope consists of two components: the app and the probe. The components are deployed as a single Docker container using the scope script. The probe is responsible for gathering information about the host on which it is running. This information is sent to the app in the form of a report. The app processes reports from the probe into usable topologies, serving the UI, as well as pushing these topologies to the UI. +--Docker host-+ | +--Container+ | .. | | | | | Browser | | | +--+ | | || | | | scope-app |<| | | | +--+ | | | | | | ^ | | | | | | | | | '' | | +-+ | | | | | scope-probe | | | | | +-+ | | | | | | | +--+ | +--+ When running Scope in a cluster, each probe sends its reports to a dedicated app. The app merges the reports from its probe into a comprehensive report that is sent to the browser. To visualize your entire infrastructure and apps running on that infrastructure, Scope must be launched on to every machine you are using. +--Docker host-+ +--Docker host-+ | +--Container+ | | +--Container+ | | | | | | | | | | | +--+ | | | | +--+ | | | | | scope-app |<--. .-->| scope-app | | | | | +--+ | | \ / | | +--+ | | | | ^ | | \/ | | ^ | | | | | | | /\ | | | | | | | +-+ | | / \ | | +-+ | | | | | scope-probe |--' '--| scope-probe | | | | | +-+ | | | | +-+ | | | | | | | | | | | +--+ | | +--+ | +--+ +--+ Scope periodically checks with our servers to see if a new version is available. You can disable this by setting: CHECKPOINT_DISABLE=true scope launch For more information, see . See Also *
Project: Grafana Loki (Observability and Analysis / Observability)
File: filesystem.md

title: Filesystem object store menuTitle: Filesystem object store description: Describes the features and limitations of using a filesystem object store with Loki. weight: 300 The filesystem object store is the easiest to get started with Grafana Loki but there are some pros/cons to this approach. Very simply it stores all the objects (chunks) in the specified directory: ```yaml storage_config: filesystem: directory: /tmp/loki/ ``` A folder is created for every tenant all the chunks for one tenant are stored in that directory. If Loki is run in single-tenant mode, all the chunks are put in a folder named `fake` which is the synthesized tenant name used for single tenant mode. See for more information. Very simple, no additional software required to use Loki when paired with the BoltDB index store. Great for low volume applications, proof of concepts, and just playing around with Loki. At some point there is a limit to how many chunks can be stored in a single directory, for example see which explains how a Loki user ran into a strange error with about 5.5 million chunk files in their file store (and also a workaround for the problem). However, if you keep your streams low (remember loki writes a chunk per stream) and use configs like `chunktargetsize` (around 1MB), `maxchunkage` (increase beyond 1h), `chunkidleperiod` (increase to match `maxchunkage`) can be tweaked to reduce the number of chunks flushed (although they will trade for more memory consumption). It's still very possible to store terabytes of log data with the filestore, but realize there are limitations to how many files a filesystem will want to store in a single directory. The durability of the objects is at the mercy of the filesystem itself where other object stores like S3/GCS do a lot behind the scenes to offer extremely high durability to your data. Running Loki clustered is not possible with the filesystem store unless the filesystem is shared in some fashion (NFS for example). However using shared filesystems is likely going to be a bad experience with Loki just as it is for almost every other application.
Project: Graylog (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project about a missing feature title: '' labels: feature assignees: '' <! Provide a general summary of the issue in the Title above --> <! Tell us how it should work. Providing more details will result in a better understanding of your needs/wishes --> <! How has this issue affected you? What are you trying to accomplish? --> <! Providing context helps us come up with a solution that is most useful in the real world --> <! Include as many relevant details about the environment you are currently working with --> Graylog Version: OpenSearch Version: MongoDB Version: Operating System: Browser version:
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-04-encoding-only-fields-except-fields.md

date: "2020-07-13" title: "New Encoding Options" description: "Vector now lets you whitelist, blacklist, and format fields when events are encoded" authors: ["binarylogic"] pr_numbers: [1915] release: "0.9.0" hideonrelease_notes: false badges: type: "enhancement" domains: ["sinks"] Vector has deprecated the root-level `encoding` option in favor of new `encoding.*` sub-options: `encoding.only_fields` - Encode only the fields listed. `encoding.except_fields` - Encode all fields except the ones listed. `encoding.codec` - The codec to use (ex: `json`). `encoding.timestamp_format` - Customize how timestamps are serialized. Upgrading is easy: ```toml title="vector.toml" [sinks.my-sink] type = "..." encoding = "json" encoding.codec = "json" encoding.exceptfields = ["meta"] # optional encoding.timestamp_format = "rfc3339" # optional ```
Project: Graylog (Observability and Analysis / Observability)
File: EntityList.md

`EntityList` with no items: ```js <EntityList bsNoItemsStyle="info" noItemsText="No items given." items={[]} /> ``` `EntityList` with two elements: ```js import { Button, Col, DropdownButton, MenuItem } from 'components/bootstrap'; import { EntityListItem } from 'components/common'; const entities = [ { id: '1', title: 'Dr. Emmett Brown', nickname: 'Doc', description: '1.21 GIGAWATTS!!!', }, { id: '2', title: 'Marty McFly', nickname: 'Marty', description: 'Nobody calls me chicken', }, ]; const items = entities.map(entity => { // You can encapsulate `EntityListItem` into its own component, // so it's easy to see what data you transform and feed into it. return ( <EntityListItem key={`entity-${entity.id}`} title={entity.title} titleSuffix={entity.nickname} description={entity.description} actions={[ <Button key={1} bsStyle="info">Edit</Button>, <DropdownButton key={2} id="more-dropdown" title="More" pullRight> <MenuItem variant="danger">Delete</MenuItem> </DropdownButton>, ]} contentRow={ <Col md={12}> <p> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. </p> </Col> }/> ) }); <EntityList bsNoItemsStyle="info" noItemsText="No items given." items={items} /> ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: agent.md

title: Troubleshoot Grafana Agent menuTitle: Grafana Agent description: Gain visibility on how many traces are being pushed to the Agent and if they are making it to the Tempo backend. weight: 472 aliases: ../operations/troubleshooting/agent/ Sometimes it can be difficult to tell what, if anything, the Grafana Agent is sending along to the backend. This document focuses on a few techniques to gain visibility on how many traces are being pushed to the Agent and if they're making it to the backend. The tracing pipeline is built on top of the which does a fantastic job of logging network and other issues. If your logs are showing no obvious errors try the following: The agent publishes a few Prometheus metrics that are useful to determine how much trace traffic it is receiving and successfully forwarding. These are a good place to start when diagnosing tracing Agent issues. ``` tracesreceiveraccepted_spans tracesreceiverrefused_spans tracesexportersent_spans tracesexportersendfailedspans ``` If metrics and logs are looking good, but you are still unable to find traces in Grafana Cloud, you can turn on . A recommend debug setup is: ```yaml traces: configs: name: default ... automatic_logging: backend: stdout roots: true ``` This will emit logs to stdout for every root span that the Agent forwards. This can be useful to see exactly which traces are being forwarded to Grafana Cloud.
Project: Ddosify (Observability and Analysis / Observability)
File: SECURITY.md

We are committed to maintaining the security and integrity of the Ddosify, and we appreciate your help in identifying and addressing potential vulnerabilities. This document outlines the process for reporting security issues, as well as our commitment to addressing them in a timely manner. We provide security updates for the following version of the Ddosify: | Version | Supported | | - | | | > `0.15.x` | | Please note that older versions may not receive security updates. We encourage you to use the of the software to benefit from the most recent security enhancements. If you believe you have discovered a security vulnerability in the Ddosify, please follow these steps to report it: Do not create a public issue on GitHub. Disclosing security vulnerabilities publicly can put users at risk. Send an email to our security team at security@ddosify.com with a detailed description of the vulnerability, including the steps to reproduce it, and any relevant information about your environment (e.g., OS, Go version, etc.). If possible, provide a minimal code sample or test case that demonstrates the vulnerability. Allow us a reasonable amount of time to investigate and address the issue before publicly disclosing it. We will make every effort to resolve the issue as soon as possible. We keep you informed of our progress in addressing the issue. We take security issues very seriously and are committed to working with you to address any vulnerabilities that you report. We will: Investigate and validate reported vulnerabilities. Work on a fix or mitigation for the issue. Provide regular updates on our progress in resolving the issue. Notify you when the issue has been resolved and provide details on the changes made. We appreciate your assistance in maintaining the security of Ddosify, and we thank you for your responsible disclosure.