foster/bitcoin-core
0
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-03-05 14:06:27 -05:00
Code Issues Activity
Bitcoin Core integration/staging tree
30005 commits 6 branches 321 tags 2.5 GiB
C++ 56.4%
C 22.6%
Python 17.7%
CMake 1%
Shell 0.8%
Other 1.3%
Find a file
W. J. van der Laan 61cefde7a7
Merge bitcoin/bitcoin#22006: tracing: first tracepoints and documentation on User-Space, Statically Defined Tracing (USDT) 
8f37f5c2a5 tracing: Tracepoint for connected blocks (0xb10c)
4224dec22b tracing: Tracepoints for in- and outbound P2P msgs (0xb10c)
469b71ae62 doc: document systemtap dependency (0xb10c)
84ace9aef1 doc: Add initial USDT documentation (0xb10c)

Pull request description:

  This PR adds documentation for User-Space, Statically Defined Tracing (USDT) as well as three tracepoints (including documentation and usage examples).

  ## Context
  The `TRACEx` macros for tracepoints and build system changes for USDT were merged in https://github.com/bitcoin/bitcoin/pull/19866 earlier this year. Issue https://github.com/bitcoin/bitcoin/issues/20981 contains discussion about potential tracepoints and guidelines for adding them (also documented with this PR). USDT was a topic in a [core-dev-meeting discussion](https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-21-19.00.moin.txt) on 21st Jan, 2021.

  - [collabora.com: An eBPF overview, part 1: Introduction](https://www.collabora.com/news-and-blog/blog/2019/04/05/an-ebpf-overview-part-1-introduction/)
  - [collabora.com: An eBPF overview, part 2: Machine & bytecode](https://www.collabora.com/news-and-blog/blog/2019/04/15/an-ebpf-overview-part-2-machine-and-bytecode/)
  - [Brendan D. Gregg's blog posts, and book on on eBPF](http://www.brendangregg.com/)
  - [Brendan D. Gregg: Linux bcc/BPF Node.js USDT Tracing](http://www.brendangregg.com/blog/2016-10-12/linux-bcc-nodejs-usdt.html)

  ## USDT? Stablecoin?

  User-space, Statically Defined Tracing (USDT) allows for more observability during development, debugging, code review, and production usage. The tracepoints make it possible to keep track of custom statistics and enable detailed monitoring of otherwise hidden internals and have little to no performance impact when unused. Linux kernels (4.x or newer) can hook into the tracepoints and execute [eBPF] programs in a kernel VM once the tracepoint is called.

  This PR includes, for example, tracepoints for in- and outbound P2P messages.

  ```
  USDT and eBPF Overview
  ======================

                  ┌──────────────────┐            ┌──────────────┐
                  │ tracing script   │            │ bitcoind     │
                  │==================│      2.    │==============│
                  │  eBPF  │ tracing │      hooks │              │
                  │  code  │ logic   │      into┌─┤►tracepoint 1─┼───┐ 3.
                  └────┬───┴──▲──────┘          ├─┤►tracepoint 2 │   │ pass args
              1.       │      │ 4.              │ │ ...          │   │ to eBPF
      User    compiles │      │ pass data to    │ └──────────────┘   │ program
      Space    & loads │      │ tracing script  │                    │
      ─────────────────┼──────┼─────────────────┼────────────────────┼───
      Kernel           │      │                 │                    │
      Space       ┌──┬─▼──────┴─────────────────┴────────────┐       │
                  │  │  eBPF program                         │◄──────┘
                  │  └───────────────────────────────────────┤
                  │ eBPF kernel Virtual Machine (sandboxed)  │
                  └──────────────────────────────────────────┘

  1. The tracing script compiles the eBPF code and loads the eBFP program into a kernel VM
  2. The eBPF program hooks into one or more tracepoints
  3. When the tracepoint is called, the arguments are passed to the eBPF program
  4. The eBPF program processes the arguments and returns data to the tracing script
  ```

  The two main [eBPF] front-ends with support for USDT are [bpftrace] an [BPF Compiler Collection (BCC)]. BCC is used for complex tools and daemons and `bpftrace` is preferred for one-liners and shorter scripts. Example tracing scripts for both are provided with this PR.

  [eBPF]: https://ebpf.io/
  [bpftrace]: https://github.com/iovisor/bpftrace
  [BPF Compiler Collection (BCC)]: https://github.com/iovisor/bcc

  This PR adds three tracepoints:
  - `net:inbound_message`
  - `net:outbound_message`
  - `valildation:block_connected`

  See `doc/tracing.md` and `contrib/tracing/` for documentation and example tracing scripts.

  ## Open Questions (Not in scope for this PR)
  -  How to use these tracepoints under macOS?
  -  Release builds with USDT support?
  -  Should and can the tracepoints be automatically tested?

  ## Todo (before undraft)
  - [x] bcc example showing how to read raw P2P messages up to 32kb
  - [x] document that you need `sys/sdt.h` from `systemtap` for USDT support in Bitcoin Core (`apt install systemtap-sdt-dev` on debian-like). See 933ab8a720
  - [ ] release notes?

ACKs for top commit:
  laanwj:
    re-ACK 8f37f5c2a5
  jb55:
    ACK 8f37f5c2a5

Tree-SHA512: a92a8a2dfcd28465f58a6e5f50d39486817ef5f51214ec40bdb02a6843b9c08ea154fadb31558825ff3a4687477b90f2a5da5d6451989eef978e128a264c289d
2021-07-27 19:47:16 +02:00
.github doc: Remove label from good first issue template 2020-08-24 09:31:24 +02:00
.tx qt: Bump transifex slug for 22.x 2021-04-21 13:46:41 +02:00
build-aux/m4 build, qt: Fix libraries linking order for Linux hosts 2021-06-06 23:25:07 +03:00
build_msvc Merge bitcoin/bitcoin#22155: wallet test: Add test for subtract fee from recipient behavior 2021-07-27 11:21:46 +02:00
ci ci: Bump Android NDK to r22 which supports std::filesystem 2021-07-18 12:10:28 +03:00
contrib tracing: Tracepoint for connected blocks 2021-07-27 17:12:38 +02:00
depends depends: use latest config.guess and config.sub for sqlite 2021-07-22 11:10:29 +08:00
doc tracing: Tracepoint for connected blocks 2021-07-27 17:12:38 +02:00
share doc: add maxuploadtarget to bitcoin.conf example 2021-05-28 12:53:17 -04:00
src tracing: Tracepoint for connected blocks 2021-07-27 17:12:38 +02:00
test Merge bitcoin/bitcoin#22442: util: improves error messages on get_previous_releases script 2021-07-25 10:19:04 +02:00
.appveyor.yml Switch Appveyor CI to VS2019 stable image 2021-06-14 20:35:00 +01:00
.cirrus.yml ci: Bump macOS image to big-sur-xcode-12.5 2021-06-02 10:03:38 +02:00
.editorconfig Add EditorConfig file. 2021-02-10 08:00:06 +01:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore build: add *~ to .gitignore 2021-05-12 18:10:47 +02:00
.python-version Bump minimum python version to 3.6 2020-11-09 17:53:47 +10:00
.style.yapf test: .style.yapf: Set column_limit=160 2019-03-04 18:28:13 -05:00
autogen.sh scripted-diff: Bump copyright of files changed in 2019 2019-12-30 10:42:20 +13:00
configure.ac build: Bump master version to 22.99.0 2021-07-20 15:27:12 +02:00
CONTRIBUTING.md doc: Fix external links (IRC, ...) 2021-05-31 17:27:57 +02:00
COPYING doc: Update license year range to 2021 2020-12-30 16:24:47 +01:00
INSTALL.md Update INSTALL landing redirection notice for build instructions. 2016-10-06 12:27:23 +13:00
libbitcoinconsensus.pc.in build: remove libcrypto as internal dependency in libbitcoinconsensus.pc 2019-11-19 15:03:44 +01:00
Makefile.am Merge bitcoin/bitcoin#22234: build: Mark print-% target as phony. 2021-07-18 13:41:24 +08:00
README.md doc: Rework internal and external links 2021-02-17 09:18:46 +01:00
REVIEWERS Update REVIEWERS: I've found that I keep track of PRs in need of review without the need for DrahtBot's automated notification :) 2021-06-10 09:00:05 +00:00
SECURITY.md doc: Remove explicit mention of version from SECURITY.md 2019-06-14 06:39:17 -04:00

README.md

Bitcoin Core integration/staging tree

https://bitcoincore.org

For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.

Further information about Bitcoin Core is available in the doc folder.

What is Bitcoin?

Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

For more information read the original Bitcoin whitepaper.

License

Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be completely stable. Tags are created regularly from release branches to indicate new official, stable release versions of Bitcoin Core.

The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.