ChimeHQ/Meter has 229 GitHub stars and 11 forks. GitHot measured 0 stars in 24 hours, 0 in 7 days, and 0 in 15 days. Last checked 2026-11-12 08:38 UTC. Last push 2024-09-15.
Library for interacting with MetricKit
計測したスター増加
- 24時間
- 0
- 7日間
- 0
- 15日間
- 0
- 1か月
- 更新が遅れています
期間ごとの純増数です。期間は重複しており、日別の値ではありません。未計測の値は空欄です。スター数は注目度の指標であり、品質の保証ではありません。
README.md
オリジナルMeter
Meter is a companion library to MetricKit. It aims to provide the following capabilities:
- API for
MXCallStackTree - Types for
MXDiagnosticemulation and coding MXMetricManager-like interface for unsupported platforms- On-device symbolication
- Account for MetricKit inconsistencies across platforms and types
- Support for custom exception reporting
If you're also looking for a way to transmit MetricKit data to your server, have a look at MeterReporter. It uses Meter under the hood, and takes care of the details.
Integration
dependencies: [
.package(url: "https://github.com/ChimeHQ/Meter")
]
Expanded API
The MetricKit API for crash reporting is unwieldy. In particular, MXCallStackTree lacks any kind of interface for interacting with its structure. Meter includes some classes that make it easier to work with. In addition to providing an API for MXCallStackTree, Meter includes types to emulate and parse MetricKit diagnostics.
let data = mxTree.jsonRepresentation()
let tree = try CallStackTree.from(data: data)
for frame in tree.callStacks[0].frames {
print("\(frame.address) \(frame.binaryName) \(frame.binaryUUID)")
}
Custom Exceptions
As of iOS 17, macOS 14, visionOS 1.0, MetricKit does capture uncaught NSExceptions. To help support older OSes, and exceptions that do not originate from places that are covered by this feature, custom exceptions are also supported. These can be created from an NSException object, which will capture all the needed runtime information to emulate a standard CallStack.
How you actually get access to the NSException is not defined by Meter. But, if you have one, the CrashDiagnostic type also includes an exceptionInfo property that can accept one of these for easy encoding.
On-Device Symbolication
The stack traces provided by MetricKit, like other types of crash logs, are not symbolicated. There are a bunch of different ways to tackle this problem, but one very convenient option is just to do it as a post-processing step on the device where the crash occurred. This does come, however, with one major drawback. It only works when you still have access to the same binaries. OS updates will almost certainly change all the OS binaries. The same is true for an app update, though in that case, an off-line symbolication step using a dSYM is still doable.
Meter provides an API for performing symbolication, via the Symbolicator protocol. The core of this protocol should be usable to symbolicate any address, and is not tied to MetricKit. But, the protocol also does include a number of convenience methods that can operate on the various MetricKit classes. The result uses the Meter's wrapper classes to return Frame instances which include a symbolInfo property. This property can be accessed directly or just re-encoded for transport.
let symbolicator = DlfcnSymbolicator()
let symPayload = symbolicator.symbolicate(payload: diagnosticPayload)
DlfcnSymbolicator
This class implements the Symbolicator protocol, and uses the functions with dlfcn.h to determine symbol/offset. This works, but does have some limitations. First, it relies on looking up symbols in the currently executing process, so it will only work if the needed binary is currently loaded.
Second, these functions return <redacted> for some binary's symbols on iOS. I know the symbol information is still accessible from the binary, so it's unclear why this is done.
This is a relatively inexpensive symbolication pass, and is a first effort. Further work here is definitely necessary.
Contributing and Collaboration
I would love to hear from you! Issues or pull requests work great. Both a Matrix space and Discord are available for live help, but I have a strong bias towards answering in the form of documentation. You can also find me on mastodon.
I prefer collaboration, and would love to find ways to work together if you have a similar project.
I prefer indentation with tabs for improved accessibility. But, I'd rather you use the system you want and make a PR than hesitate because of whitespace.
By participating in this project you agree to abide by the Contributor Code of Conduct.
関連プロジェクトを探す
Asabeneh/30-Days-Of-Python
30 Days of Python プログラミングチャレンジは、Python プログラミング言語を 30 日で学ぶためのステップバイステップのガイドです。このチャレンジは 100 日以上かかることもあります。自分のペースで進めてください。こちらの動画も役立つかもしれません: https://www.youtube.com/channel/UC7PNRuno1rzYPb1xLa4yktw
78,618 スターgrafana/grafana
オープンで組み合わせ可能なオブザーバビリティおよびデータ可視化プラットフォームです。Prometheus、Loki、Elasticsearch、InfluxDB、Postgres など、複数のソースからメトリクス、ログ、トレースを可視化できます。
77,859 スターredis/redis
リアルタイムのデータ駆動型アプリケーションを構築する開発者にとって、Redis は最も選ばれ、最速で、機能が最も豊富なキャッシュ、データ構造サーバー、ドキュメントおよびベクトルクエリエンジンです。
77,472 スターapache/superset
Apache Superset は、データ可視化とデータ探索のためのプラットフォームです。
75,495 スター