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

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/zfsadaptivereplacement_cache.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "ZFS Adaptive Replacement Cache" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Filesystem/ZFS" 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/filesystem.svg" width="150"/> Plugin: proc.plugin Module: /proc/spl/kstat/zfs/arcstats <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors ZFS Adadptive Replacement Cache (ARC) statistics. 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. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | zfs.arc_size | arcsz, target, min, max | MiB | | zfs.l2_size | actual, size | MiB | | zfs.reads | arc, demand, prefetch, metadata, l2 | reads/s | | zfs.bytes | read, write | KiB/s | | zfs.hits | hits, misses | percentage | | zfs.hits_rate | hits, misses | events/s | | zfs.dhits | hits, misses | percentage | | zfs.dhits_rate | hits, misses | events/s | | zfs.phits | hits, misses | percentage | | zfs.phits_rate | hits, misses | events/s | | zfs.mhits | hits, misses | percentage | | zfs.mhits_rate | hits, misses | events/s | | zfs.l2hits | hits, misses | percentage | | zfs.l2hits_rate | hits, misses | events/s | | zfs.listhits | mfu, mfughost, mru, mru_ghost | hits/s | | zfs.arcsizebreakdown | recent, frequent | percentage | | zfs.memory_ops | direct, throttled, indirect | operations/s | | zfs.importantops | evictskip, deleted, mutexmiss, hashcollisions | operations/s | | zfs.actual_hits | hits, misses | percentage | | zfs.actualhitsrate | hits, misses | events/s | | zfs.demanddatahits | hits, misses | percentage | | zfs.demanddatahits_rate | hits, misses | events/s | | zfs.prefetchdatahits | hits, misses | percentage | | zfs.prefetchdatahits_rate | hits, misses | events/s | | zfs.hash_elements | current, max | elements | | zfs.hash_chains | current, max | chains | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | zfs.memory_ops | number of times ZFS had to limit the ARC growth in the last 10 minutes | No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Elastic (Observability and Analysis / Observability)
File: st_disjoint.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns whether the two geometries or geometry columns are disjoint. This is the inverse of the <<esql-stintersects,STINTERSECTS>> function. In mathematical terms: ST_Disjoint(A, B) A B = ``` FROM airportcityboundaries | WHERE STDISJOINT(cityboundary, TO_GEOSHAPE("POLYGON((-10 -60, 120 -60, 120 60, -10 60, -10 -60))")) | KEEP abbrev, airport, region, city, city_location ```
Project: Grafana (Observability and Analysis / Observability)
File: tracing-best-practices.md

description: Use best practices to plan how you implement tracing. keywords: grafana tempo best practices tracing labels: products: cloud enterprise oss menuTitle: Best practices title: Best practices for tracing weight: 250 This page provides some general best practices for tracing. {{< docs/shared source="tempo" lookup="best-practices-traces.md" version="<TEMPO_VERSION>" >}}
Project: Netdata (Observability and Analysis / Observability)
File: inbound_packets_dropped_ratio.md

Packet drops indicate that your system received some packets but could not process them. A sizeable amount of packet drops can consume significant amount of resources in your system. Some reasons that packets drops occurred in your system could be: Your system receives packets with bad VLAN tags. The packets you are receiving are using a protocol that is unknown to your system. You receive IPv6 packets, but your system is not configured for IPv6. All these packets consume resources until being dropped (and for a short period after). For example, your NIC stores them in a ring-buffer until they are forwarded to the destined subsystem or userland application for further process. Netdata calculates the ratio of inbound dropped packets for your wired network interface over the last 10 minutes. There are cases in which traffic is routed to your host due to the existence of multiple VLAN in your network. Identify VLAN tagged packet in your interface. ``` tcpdump -i <your_interface> -nn -e vlan ``` Monitor the output of the `tcpdump`, identify VLANs which may exist. If no output is displayed, your interface probably uses traditional ethernet frames. Depending on your network topology, you may consider removing unnecessary VLANs from the switch trunk port toward your host. To view the maximum RX ring buffer size: ``` ethtool -g enp1s0 ``` If the values in the Pre-set maximums section are higher than in the current hardware settings section, increase RX ring buffer: ``` enp1s0 rx 4080 ``` Verify the change to make sure that you no longer receive the alarm when running the same workload. To make this permanently, you must consult your distribution guides. Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development.
Project: SkyWalking (Observability and Analysis / Observability)
File: v9-version-upgrade.md

Starting from v9, SkyWalking introduces the new core concept . A layer represents an abstract framework in computer science, such as Operating System(OS_LINUX layer), Kubernetes(k8s layer). This kind of layer would be catalogs on the new of various services/instances detected by different technologies. The query-protocol has been used. The compatibility with previous releases is as below. The query-protocol is provided on the top of the v2 implementation. All metrics are compatible with the previous data format, so you wouldn't lose metrics. Notice Incompatibility (1), the UI template configuration protocol is incompatible. The has been changed by following the design of new . So, the RocketBot UI can't work with the v9 backend. You need to remove `ui_template` index/template/table in your chosen storage, and reboot OAP in `default` or `init` mode. MAL: add an required argument `Layer`. Previous MAL expressions should add this argument. LAL: add function `layer`. If don't set it manual, the default layer is `GENERAL` and the logs from `ALS` the default layer is `mesh`. StorageAdd `serviceid` `shortname` and `layer` columns to table `ServiceTraffic`. These data would be incompatible with previous versions. Make sure to remove the older `ServiceTraffic` table before OAP(v9) starts. OAP would generate the new table in the start procedure, and recreate all existing services when traffic comes. Since V9.1, SQL Database: move `Tags list` from `Segment`, `Logs`, `Alarms` to their additional tables, remove them before OAP starts. UI-template: Re-design for V9. Make sure to remove the older `ui_template` table before OAP(v9) starts.
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-17-add-fields-transform-templating.md

date: "2020-04-13" title: "The Add Fields Transform Supports Templating" description: "Use Vector's templating syntax to add new fields" authors: ["binarylogic"] pr_numbers: [1799] release: "0.8.0" hideonrelease_notes: true badges: type: "enhancement" domains: ["transforms"] transforms: ["add_fields"] Vector offers a that you can use to build dynamic values in your files. This has now been added to the , enabling the ability to create fields from other fields values.
Project: Weave Scope (Observability and Analysis / Observability)
File: TODO.md

[ ] Better constructors, options handling [ ] Functions for callback settings after connection created. [ ] Better options for subscriptions. Slow Consumer state settable, Go routines vs Inline. [ ] Move off of channels for subscribers, use syncPool linkedLists, etc with highwater. [ ] Test for valid subjects on publish and subscribe? [ ] SyncSubscriber and Next for EncodedConn [ ] Fast Publisher? [ ] pooling for structs used? leaky bucket? [ ] Timeout 0 should work as no timeout [x] Ping timer [x] Name in Connect for gnatsd [x] Asynchronous error handling [x] Parser rewrite [x] Reconnect [x] Hide Lock [x] Easier encoder interface [x] QueueSubscribeSync [x] Make nats specific errors prefixed with 'nats:' [x] API test for closed connection [x] TLS/SSL [x] Stats collection [x] Disconnect detection [x] Optimized Publish (coalescing) [x] Do Examples via Go style [x] Standardized Errors
Project: Netdata (Observability and Analysis / Observability)
File: net.inet.tcp.states.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/net.inet.tcp.states.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "net.inet.tcp.states" 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/network.svg" width="150"/> Plugin: freebsd.plugin Module: net.inet.tcp.states <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> 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. A counter for TCP connections. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | ipv4.tcpsock | connections | active connections | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | ipv4.tcpsock | IPv4 TCP connections 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]` 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 | |:-|:--|:-|:--:| | net.inet.tcp.states | Enable or disable TCP state metric. | yes | no | </details> There are no configuration examples.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: micro-service-architectures.md

title: Feature Flags and the Micro-Service Architecture Sometimes it can be tricky to figure out how to map Flagsmith Projects to your own Applications. When you are working on an application that has 1 core server-side service, it's generally fairly obvious to map 1 Flagsmith Project to your server-side application. Things get a bit more tricky when you start working with a micro-service architecture. Let's say you have 5 micro-services that are all employed to power your front end application. Should you create a single Flagsmith Project to cover all 5 services? Or 5 Projects, one for each service? Or maybe some number in between? Like a lot of problems in Software Engineering, the right answer is "it depends". Maybe not the most helpful answer, but easily the most accurate! What it boils down to is coupling. Generally if we are looking at a collection of micro-services that are tightly coupled, they may well be a good candidate for sharing a single Flagsmith project. On the other had, if your services are loosely coupled with will defined interface boundaries, you will probably want to go with mapping 1 Flagsmith project to 1 micro-service. It really boils down to interface boundaries. If you are writing a service that has an agreed upon, established API interface, the services consuming your API really don't care too much about your implementation. That being the case, by definition they shouldn't really care about your feature flags either. Why would they? On the other hand, if you are working on a service that is tightly coupled with another, you probably do care about their flags. Let's take an example. Imagine three micro-services that share a common database. You want to make a schema change to the database, but that means coordinating the new schema code amongst your 3 services. Coordinating deployments is fraught with danger, but using feature flags is a great solution to this problem. In this case, having the 3 micro-services sharing the 1 flagsmith project is really helpful If you have a single Flagsmith project powering several micro-services, you need to be aware of the following aspects. All the team members of the project will have access to your flags. If an engineer on another team doesn't really have any business managing your production flags, it might be a sign to split out into 2 Flagsmith projects. It can be helpful for segment definitions to be shared amongst micro-services. That would point to having a single Flagsmith project. If the context that your users access your service is the same/similar, sharing segments makes a lot of sense.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-expression_delete.md

category: Expression apiurl: '/api/v1/expression/#{expression_id}' title: "Delete Expression" type: 'DELETE' sample_doc: 'expression.html' layout: default Required ex. /api/v1/expression/5 ```Status: 200``` ```{"message":"expression:5 has been deleted"}```
Project: Vector (Observability and Analysis / Observability)
File: new_relic.md

title: New Relic description: Deliver events to component_kind: sink layout: component tags: ["new relic", "newrelic", "component", "sink", "logs", "metrics"] aliases: ["/docs/reference/configuration/sinks/newreliclogs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: SkyWalking (Observability and Analysis / Observability)
File: service-agent.md

The service auto instrument agent is a subset of language-based native agents. This kind of agents is based on some language-specific features, especially those of a VM-based language. Many users learned about these agents when they first heard that "Not a single line of code has to be changed". SkyWalking used to mention this in its readme page as well. However, this does not reflect the full picture. For end users, it is true that they no longer have to modify their codes in most cases. But it is important to understand that the codes are in fact still modified by the agent, which is usually known as "runtime code manipulation". The underlying logic is that the auto instrument agent uses the VM interface for code modification to dynamically add in the instrument code, such as modifying the class in Java through `javaagent premain`. In fact, although the SkyWalking team has mentioned that most auto instrument agents are VM-based, you may build such tools during compiling time rather than runtime. Auto instrument is very helpful, as you may perform auto instrument during compiling time, without having to depend on VM features. But there are also certain limitations that come with it: Higher possibility of in-process propagation in many cases. Many high-level languages, such as Java and .NET, are used for building business systems. Most business logic codes run in the same thread for each request, which causes propagation to be based on thread ID, in order for the stack module to make sure that the context is safe. Only works in certain frameworks or libraries. Since the agents are responsible for modifying the codes during runtime, the codes are already known to the agent plugin developers. There is usually a list of frameworks or libraries supported by this kind of probes. For example, see the . Cross-thread operations are not always supported. Like what is mentioned above regarding in-process propagation, most codes (especially business codes) run in a single thread per request. But in some other cases, they operate across different threads, such as assigning tasks to other threads, task pools or batch processes. Some languages may even provide coroutine or similar components like `Goroutine`, which allows developers to run async process with low payload. In such cases, auto instrument will face problems. So, there's nothing mysterious about auto instrument. In short, agent developers write an activation script to make instrument codes work for you. That's it! If you want to learn about manual instrument libs in SkyWalking, see the section.
Project: SkyWalking (Observability and Analysis / Observability)
File: config_dump.md

SkyWalking OAP behaviors could be controlled through hundreds of configurations. It is hard to know what is the final configuration as all the configurations could be overrided by system environments. The core config file lists all the configurations and their default values. However, it is still hard to know the runtime value. Scratch is a tool to dump the final configuration. It is provided within OAP rest server, which could be accessed through HTTP GET `http://{core restHost}:{core restPort}/debugging/config/dump`. ```shell curl http://127.0.0.1:12800/debugging/config/dump cluster.provider=standalone core.provider=default core.default.prepareThreads=2 core.default.restHost=0.0.0.0 core.default.searchableLogsTags=level,http.status_code core.default.role=Mixed core.default.persistentPeriod=25 core.default.syncPeriodHttpUriRecognitionPattern=10 core.default.restIdleTimeOut=30000 core.default.dataKeeperExecutePeriod=5 core.default.topNReportPeriod=10 core.default.gRPCSslTrustedCAPath= core.default.downsampling=[Hour, Day] core.default.serviceNameMaxLength=70 core.default.gRPCSslEnabled=false core.default.restPort=12800 core.default.serviceCacheRefreshInterval=10 ... ``` All booting configurations with their runtime values are listed, including the selected provider for each module. Some of the configurations contain sensitive values, such as username, password, token, etc. These values would be masked in the dump result. For example, the `storage.elasticsearch.password` in the following configurations, ```yaml storage: selector: ${SW_STORAGE:h2} elasticsearch: password: ${SWESPASSWORD:""} ``` It would be masked and shown as `` in the dump result. ```shell curl http://127.0.0.1:12800/debugging/config/dump ... storage.elasticsearch.password= ... ``` By default, we mask the config keys through the following configurations. ```yaml keywords4MaskingSecretsOfConfig: ${SWDEBUGGINGQUERYKEYWORDSFORMASKINGSECRETS:user,password,token,accessKey,secretKey,authentication} ``` By default, this service is open for helping users to debug and diagnose. If you want to disable it, you need to diable the whole `debugging-query` module through setting `selector=-`. ```yaml debugging-query: selector: ${SWDEBUGGINGQUERY:-} ```
Project: Grafana (Observability and Analysis / Observability)
File: UPGRADING_DEPENDENCIES.md

Upgrading Go or Node.js requires making changes in many different files. See below for a list and explanation for each. Drone `grafana/build-container` Appveyor Dockerfile Drone `grafana/build-container` Appveyor Dockerfile `.github/workflows/publish.yml` The Grafana project uses to manage dependencies on external packages. This requires a working Go environment with version 1.11 or greater installed. To add or update a new dependency, use the `go get` command: ```bash go get example.com/some/module/pkg go get example.com/some/module/pkg@vX.Y.Z ``` Tidy up the `go.mod` and `go.sum` files: ```bash go mod tidy ``` You have to commit the changes to `go.mod` and `go.sum` before submitting the pull request. To understand what the actual dependencies of `grafana-server` are, one could run it with `-vv` flag. This might produce an output, different from `go.mod` contents and `-vv` option is the source of truth here. It lists the modules compiled into the executable, while `go.mod` lists also test and weak transitive dependencies (modules, used in some package, which is not in use by itself). If you are interested in reporting a vulnerability in a dependency module - please consult `-vv` output, maybe the "dependency" is not a dependency as such. If you need to upgrade a direct or indirect dependency, you can do it like so, $MODULE being the dependency in question: `go get -u $MODULE`. The corresponding entry in go.mod should then have the version you specified; if it's an indirect dependency, the entry should have the `// indirect` comment. Follow this by executing `go mod tidy`, to ensure that go.mod and go.sum are up to date. If the indirect dependency turns out to not be used (transitively) by any of our packages, `go mod tidy` will actually strip it from go.mod. In that case, you can just ignore it since it isn't used in the end. Updated using `yarn`. `package.json` Our CI builds run on Drone. `.circleci/config.yml`. nodejs golang grafana/build-container (our custom docker build container) The main build steps (in Drone) happen using a custom Docker image that comes pre-baked with some of the necessary dependencies. Link: fpm nodejs golang crosscompiling (several compilers) Main and release builds trigger test runs on Appveyors build environment so that tests will run on Windows. `appveyor.yml` nodejs golang There is a Docker build for Grafana in the root of the project that allows anyone to build Grafana just using Docker. `Dockerfile` nodejs golang Please send out a notice in the grafana-dev slack channel when updating Go or Node.js to make it easier for everyone to update their local developer environments.