Pith. sign in

REVIEW 3 major objections 6 minor 73 references

Observability in Fog Computing

T0 review · 3 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This chapter claims that fog computing can support full observability (metrics, logs, and traces) with low resource overhead, supported by a testbed where device CPU stayed below 12%.

desk verdict A competent survey of fog observability that overstates its small testbed's support for 'low overhead'; useful as a reference, not as a new research result. read the letter →

arxiv 2411.17753 v1 pith:SVESEH2M submitted 2024-11-25 cs.DC

Aleteia Araujo (1 , 2) , Breno Costa (1) , Joao Bachiega Jr (1) , Leonardo R. Carvalho (1) , Rajkumar Buyya (2) ((1) University of Brasilia Brazil , (2) The University of Melbourne Australia) This is my paper · ORCID
classification cs.DC
keywords FogComputingObservabilityIoTMetricsLogsTracesMonitoringOpenTelemetry
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This chapter argues that observability in fog computing—collecting metrics, logs, and traces so operators can see a system's internal state—is practical without overwhelming resource-limited devices. It proposes a six-step data lifecycle that keeps most telemetry on fog nodes and archives only older data to the cloud, plus an agent–transformer–server architecture that maps onto existing open-source tools. The supporting experiment on a four-device, two-fog-node testbed reports device-side overhead below 12% CPU and 150 MiB memory, with weekly telemetry volume under 1% of the application's normal data flow. The conclusion is that fog environments can carry full observability at a modest resource cost, while heterogeneity, scattered data sources, resource consumption, and security remain open challenges.

What carries the argument

The load-bearing mechanism is the Observability Data Life Cycle (ODLC), six stages—collection, IoT storage, transmission to fog, fog storage, analysis and visualization, cloud storage and analysis—that partition telemetry work so IoT devices only collect and forward while fog and cloud nodes absorb storage and analysis. The observability index and its synergy term formalize why all three domains are worth collecting together. The agent–transformer–server component model and the three topologies (centralized, decentralized, distributed) give the deployment structure that the testbed instantiates with open-source containers.

What would settle it

Run the same open-source observability stack on a larger, more heterogeneous fleet (hundreds of IoT devices) over low-bandwidth or intermittent links with the full default metric set; if IoT-device CPU or memory rises sharply, fog-node CPU exceeds 25%, or application latency degrades measurably compared with a no-telemetry baseline, the low-overhead claim fails in that regime. Alternatively, a side-by-side trial showing no reduction in time-to-restore for a metrics–logs–traces deployment versus metrics-only monitoring would weaken the practical benefit claim.

Watch

Extended reading notes

Core claim

The central claim is that a fog environment can run all three pillars of observability—metrics, logs, and traces—alongside its applications, as long as the telemetry lifecycle keeps the load off constrained IoT devices. The paper defines an observability index that counts the available domains and adds a synergy term $\mathrm{Metrics}\times\mathrm{Logs}\times\mathrm{Traces}$, which is 1 only when time-correlated data exist in more than one domain; this makes cross-domain analysis part of what observability means, not an extra. It then splits the problem into collection, IoT storage, transmission, fog storage, analysis and visualization, and cloud archiving, and into agent, transformer, and server components. The experimental basis is an observability stack (NodeExporter, Filebeat, OpenTelemetry, Prometheus, Elasticsearch, Jaeger, Grafana) deployed on a smart-city roadside-monitoring application, where IoT-device CPU stayed below 12%, memory below 150 MiB, fog-node server overhead reached 25% CPU and 5 GiB memory, and a week of observability data totalled about 2 GB. The authors conclude that these numbers make higher observability achievable in fog computing with low resource overhead.

Load-bearing premise

The measured low overhead from a four-device, two-fog-node testbed generalizes to real fog environments, even though the metric set was manually limited, fog-node retention was capped at one week, and the network was not stressed.

Editorial extensions

If this is right

  • Operators can deploy a complete metrics–logs–traces stack on fog nodes using open-source tools, with IoT-device overhead under 12% CPU and under 150 MiB memory.
  • Fog-node server components, not the device agents, are the resource bottleneck: Prometheus, Elasticsearch, Jaeger, and Grafana consumed up to 25% CPU and 5 GiB memory on the fog node.
  • Restricting metrics to application-relevant ones and keeping data on the fog node for a week keeps weekly telemetry to about 2 GB, under 1% of the application's 5G data volume.
  • Cross-domain time-correlation (the synergy term) yields more observability than any single instrumented domain, which justifies running all three pillars despite the added load.
  • Automatic cloud archival of aged observability data prevents fog storage and IoT device storage from being saturated, keeping the lifecycle sustainable.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The reported overhead numbers come from a testbed with only four IoT devices and two fog nodes; a production-scale fleet with full default metric sets and lossy networks could push device CPU or fog-node memory well above these figures.
  • The paper discusses adaptive collection and eBPF as future directions; a natural testable extension is an adaptive controller that reduces collection frequency or drops a domain when device or network load rises, which the testbed architecture could support but does not evaluate.
  • If the observability index's synergy term is meant to predict operational value, the next experiment would be to compare mean time to restore with and without cross-domain correlation, holding tooling constant.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper is a survey/tutorial chapter on observability in Fog Computing. It reviews the three pillars of observability (metrics, logs, traces), introduces the Observability Data Life Cycle (ODLC), discusses challenges and approaches, presents a three-component architecture and three topologies, surveys open-source tools for metrics, logs, traces, storage, and visualization, and describes a solution example based on the Mobile IoT-RoadBot Smart City application. The solution example reports a testbed with 4 IoT devices, 2 Fog nodes, and 1 cloud VM running NodeExporter, Filebeat, OpenTelemetry, Prometheus, Elasticsearch, Jaeger, and Grafana, and it reports resource overhead figures (IoT CPU <12%, IoT memory <150 MiB, Fog node CPU up to 25%, Fog node memory 5 GiB, 2 GB weekly observability data). The chapter concludes that the experiments showed it is possible to obtain the benefits of higher observability in Fog at low resource overhead.

Significance. If taken as a survey, the chapter provides a useful consolidation of concepts, a clear enumeration of challenges, and a convenient tool table (Table 1.2) that practitioners could use to assemble an observability stack. The architecture and topology discussion are reasonable and well referenced. The solution example is a concrete demonstration that an open-source observability stack can be deployed in a Fog-like environment, and the reported overhead numbers are a starting point for further evaluation. However, the paper's only experimental evidence for the benefit/cost tradeoff is the solution example, and it measures only resource consumption, not any benefit metric. The small, manually tuned testbed means the empirical claim 'low overhead' is not yet established at scale. These limitations do not invalidate the survey content, but they require the empirical claim to be substantially qualified. There are no machine-checked proofs or public datasets; the main strengths are the descriptive synthesis and the practical tool-oriented overview.

major comments (3)
  1. [§1.6 (Solution Example, final sentence)] The claim that 'the experiments showed that it is possible to collect the benefits of achieving a higher level of observability for a system in a Fog computing environment with a low overhead in terms of resource usage' is not supported by the reported data. The experiment measures only resource overhead (IoT CPU/memory, Fog CPU/memory, and weekly data volume) and no benefit metric such as time-to-detection, mean-time-to-repair, availability, or troubleshooting outcome. The 'benefits' are imported from the general observability discussion rather than from the experiment itself. Please reword the claim to state what was actually demonstrated, for example, the feasibility of deploying a three-pillar observability stack with the measured resource overhead, or add a quantitative benefit metric to the evaluation.
  2. [§1.6 (overhead figures)] The label 'low overhead' is not established for the Fog node. The reported 25% CPU and 5 GiB memory are presented without the total capacity of the two Fog nodes, the baseline application load, or run-to-run variance. Since §1.2.1 defines Fog nodes as potentially smartphones, routers, or notebooks, 5 GiB is not self-evidently low and could be a large fraction of the memory of a resource-restricted node. Please report the node capacities, baseline utilization, and experimental variance, or qualify the 'low' characterization to the specific node types used in the testbed.
  3. [§1.6 (measurement configuration and generalizability)] The overhead figures are obtained under explicitly tuned conditions: the metric set was manually limited to 'only the ones of interest to the application', the retention window on the Fog node was capped at one week, and the testbed includes only 4 IoT devices, 2 Fog nodes, and 1 cloud VM. No scaling behavior is given for larger metric sets, larger device fleets, or unreliable network conditions. As written, the claim refers to 'a Fog computing environment' generally, which overgeneralizes from this single configuration. Please add a limitations paragraph that explicitly scopes the overhead results to the described testbed and avoids implying universal low overhead.
minor comments (6)
  1. [§1.5.2 (Filebeat)] The sentence 'The provided LaTeX text has been paraphrased as requested.' appears in the manuscript and is clearly a pipeline artifact; it should be removed.
  2. [§1.5.2 and Table 1.2] The tool name 'Logtash' is a misspelling of 'Logstash'. In Table 1.2, the Fluentd row is duplicated; the second row labeled 'Fluentd' describes 'Part of ELK stack', which actually refers to Logstash.
  3. [§1.7 (Future Directions)] In the list of interchangeable data format tools, 'collected' should be 'collectd' (the system statistics collection daemon).
  4. [§1.2.3 (Transmission step)] There is a missing space in 'a suitableFog observability solution'; it should read 'a suitable Fog observability solution'.
  5. [Equation 1.3 and surrounding text] The notation for the X operator, especially the expansion '(IDiXIDjXIDk)' and the 'IDixIDj' expressions, is not typeset with standard mathematical formatting and is difficult to parse. Please rewrite using clear set operators or relational symbols.
  6. [Abstract] The phrase 'metrics, log, and traces' should be 'metrics, logs, and traces' for consistency with the rest of the chapter.

Circularity Check

3 steps flagged · score 4.0 of 10

The observability index is the authors' own definition, so the claim that more domains and synergy increase observability is true by construction; the Section 1.6 testbed measures overhead but not benefits, yet the conclusion asserts benefits were collected.

  1. self definitional [Section 1.2.2, Equations 1.1-1.4]
    "Having more instrumentation domains available means a higher observability level. ... We defined an observability index in a previous study [29]. ... We added the synergistic interactions between them as well, as in Equation 1.3: Observability = Metrics + Logs + Traces + (Metrics X Logs X Traces). ... This definition shows that to increase the observability of a system, it is important not only to collect the information from the instrumentation domains ... It is also relevant to be prepared to learn from their interactions."

    The statement that more domains plus cross-domain synergy yield higher observability is not derived from external data or theory; it is an immediate consequence of the authors' own Eq. 1.3, where observability is defined as Metrics + Logs + Traces plus an interaction term. The text itself says 'This definition shows', making the structure explicit: the conclusion is the definition. The only cited source for this index is the authors' prior work [29], so the definition is not independently established in this chapter.

  2. self citation load bearing [Section 1.1, Introduction]
    "We systematically reviewed the literature on Fog monitoring solutions in our previous work [12]. We have found that no available proposal could adequately manage the collection of metrics, logs, and traces simultaneously in a Fog Computing environment."

    The chapter's motivating gap — that no existing proposal can manage metrics, logs, and traces simultaneously in Fog — is justified solely by the authors' own prior systematic review [12], whose authors overlap with the present paper. No independent survey or external source is cited for this 'no available proposal' claim. The gap is load-bearing for the chapter's framing, and if that prior review is incomplete or biased, the motivation has no independent support. This is a self-citation chain rather than an externally established fact.

1 more flagged steps
  1. other [Section 1.6, final sentence]
    "The experiments showed that it is possible to collect the benefits of achieving a higher level of observability for a system in a Fog computing environment with a low overhead in terms of resource usage."

    The experiment reported in Section 1.6 measures only resource overhead (IoT CPU under 12%, memory under 150 MiB; Fog CPU up to 25%, memory 5 GiB; 2 GB weekly data volume) and does not measure any benefit variable such as time-to-detection, mean-time-to-repair, availability, or troubleshooting outcome. The 'benefits' of observability are imported from the earlier discussion and from the authors' definitional observability index, not from the testbed. Thus the concluding 'collect the benefits' claim reduces to the prior definition/assumption plus the measured overhead; the benefit part is not an experimental result.

full rationale

This is primarily a survey/tutorial chapter, so much of its content is expository rather than a formal derivation chain. The main place where a result is claimed to follow from an experiment is Section 1.6, but that section measures only overhead and data volume; the 'benefits' of observability are assumed from the definition of observability (Eq. 1.3) and from general troubleshooting arguments, not measured. The observability index is openly introduced as the authors' own definition ('We defined an observability index...'), so statements such as 'more domains and synergy increase observability' are tautological rather than empirical. The chapter also relies on the authors' own prior survey [12] for its literature-gap claim and on [29] for the ODLC and testbed; these self-citations are load-bearing for the framing. The testbed limitations are acknowledged in the text (manually restricted metric set, one-week retention, small scale), which further limits the generality of the overhead claim but is not itself circularity. Overall, the central claim 'benefits at low overhead' is partially circular because the benefit side is definitional/assumed while only the overhead side is measured; score 4 reflects partial, not total, circularity, since the chapter contains substantial independent survey content on tools, architectures, and challenges.

Assumptions & free parameters 0 free parameters · 5 assumptions · 2 invented entities

The central claim rests on domain assumptions about the value of observability, the three-pillar framework, the fog architecture, the ODLC model, and the transferability of the prior testbed results. No free parameters are fitted because the paper contains no new empirical fitting. Two conceptual entities (ODLC and the observability index) are introduced as frameworks without independent evidence.

assumptions (5)
  • domain assumption A higher level of observability speeds up troubleshooting and increases availability.
    Stated in the abstract and introduction (Section 1.1) as motivation; no controlled experiment in this paper demonstrates a causal link between observability level and reduced time to restore.
  • domain assumption Metrics, logs, and traces are the three critical instrumentation domains and cover the information needed for observability.
    The paper adopts this as given from the observability literature [6,24] and uses it to define the observability index.
  • domain assumption The three-layer IoT-Fog-Cloud architecture and the NIST six characteristics of fog computing hold.
    Used as the framework for the proposed architecture and life cycle; accepted from cited standards [1,2].
  • domain assumption The Observability Data Life Cycle (ODLC) steps are a valid model of data flow in fog environments.
    Proposed in the authors' prior work [29] and presented without independent validation.
  • domain assumption The testbed results from [29] are accurate and transferable.
    The 'solution example' in Section 1.6 reports overhead numbers and data volumes from the authors' prior deployment; no raw data or statistical validation is provided here.
invented entities (2)
  • Observability Data Life Cycle (ODLC)
    purpose: A six-step model (Collection, IoT storage, Transmission, Fog storage, Analysis/visualization, Cloud storage) describing how observability data should flow in fog environments.
    Presented as a framework in Section 1.2.3 and attributed to prior work [29]; no quantitative validation that following the ODLC improves outcomes.
  • Synergistic observability index (Equation 1.3)
    purpose: A formula adding a synergy term (Metrics x Logs x Traces) to the simple count of available instrumentation domains, to justify cross-domain analysis.
    Defined in Section 1.2.2 from previous work [29]; it is a design definition, not an empirically derived measure, and its parameters are binary values chosen by definition.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Observability in Fog Computing." pith.science (2026). https://pith.science/paper/SVESEH2M

@misc{pith2026241117753,
  author       = {Pith},
  title        = {Pith review of: Observability in Fog Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SVESEH2M}},
  note         = {Machine review of arXiv:2411.17753}
}
read the original abstract

Fog Computing provides computational resources close to the end user, supporting low-latency and high-bandwidth communications. It supports IoT applications, enabling real-time data processing, analytics, and decision-making at the edge of the network. However, the high distribution of its constituent nodes and resource-restricted devices interconnected by heterogeneous and unreliable networks makes it challenging to execute service maintenance and troubleshooting, increasing the time to restore the application after failures and not guaranteeing the service level agreements. In such a scenario, increasing the observability of Fog applications and services may speed up troubleshooting and increase their availability. An observability system is a data-intensive service, and Fog Computing could have its nodes and channels saturated with an additional load. In this work, we detail the three pillars of observability (metrics, log, and traces), discuss the challenges, and clarify the approaches for increasing the observability of services in Fog environments. Furthermore, the system architecture that supports observability in Fog, related tools, and technologies are presented, providing a comprehensive discussion on this subject. An example of a solution shows how a real-world application can benefit from increased observability in this environment. Finally, there is a discussion about the future directions of Fog observability.

Figures

Figures reproduced from arXiv: 2411.17753 by the authors.

Figure 1.1
Figure 1.1. Overview of the Fog Computing architecture. [PITH_FULL_IMAGE:figures/full_fig_p006_1_1.png] view at source ↗
Figure 1.2
Figure 1.2. Resource abstraction on a Fog node. for proper actuation of the system when needed. In the context of Fog Computing, observability is crucial for maintaining desired QoS levels and meeting SLA obligations. By providing real-time visibility into the performance of Fog services, observability enables operators to proactively manage QoS and take corrective action to prevent SLA violations [21, 22, 23]. Observability to… view at source ↗
Figure 1.3
Figure 1.3. Fog observability’s data life cycle. 1. Collection The data are collected in the initial step of the Fog observability data life cycle. This can happen in many ways depending on the instrumentation domain in place. Metrics can be acquired from the operating system by utilizing system calls that report the amount of available resources (e.g., CPU, memory, disk storage). Platforms such as container management systems … view at source ↗
Figures from the paper (3 more)
Figure 1.4
Figure 1.4. Figure 1.4: Components of a Fog Observability System. [PITH_FULL_IMAGE:figures/full_fig_p017_1_4.png]
Figure 1.5
Figure 1.5. Figure 1.5: Topologies of observability systems: a) Centralized; b) Decentralized; c) Distributed. [PITH_FULL_IMAGE:figures/full_fig_p018_1_5.png]
Figure 1.6
Figure 1.6. Figure 1.6: Fog observability system composed of open-source tools [29]. [PITH_FULL_IMAGE:figures/full_fig_p023_1_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

73 extracted references · 73 canonical work pages

  1. [12]

    Breno Costa, Joao Bachiega Jr, Leonardo Rebou¸ cas Carvalho, Michel Rosa, Aleteia Araujo: Monitoring fog computing: A review, taxonomy and open challenges, Computer Networks, 109189 (2022) 27 28 BIBLIOGRAPHY

    work page 2022

  2. [29]

    Breno Costa, Abhik Banerjee, Prem Prakash Jayaraman, Leonardo R. Carvalho, Jo˜ ao Bach- iega, Aleteia Araujo: Achieving Observability on Fog Computing with the Use of Open- Source Tools, Mobile and Ubiquitous Systems: Computing, Networking and Services, ed. by Arkady Zaslavsky, Zhaolong Ning, Vana Kalogeraki, Dimitrios Georgakopoulos, Panos K. Chrysanthis...

    work page 2024

  3. [1]

    Bonomi, Flavio, Milito, Rodolfo, Zhu, Jiang, Addepalli, Sateesh: Fog Computing and Its Role in the Internet of Things, Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing (ACM 2012) 13 - 16

    work page 2012

  4. [2]

    Michaela Iorga, Larry Feldman, Robert Barton, Michael Martin, Nedim Goren, Charif Mah- moudi: Fog Computing Conceptual Model, (2018-03-14 2018)

    work page 2018

  5. [3]

    Ranesh Kumar Naha, Saurabh Garg, Dimitrios Georgakopoulos, Prem Prakash Jayaraman, Longxiang Gao, Yong Xiang, Rajiv Ranjan: Fog computing: Survey of trends, architectures, requirements, and research directions, IEEE Access 6, 47980 - 48009 (2018)

    work page 2018

  6. [4]

    Luis M Vaquero, Felix Cuadrado, Yehia Elkhatib, Jorge Bernal-Bernabe, Satish N Srirama, Mohamed Faten Zhani: Research challenges in nextgen service orchestration, Future Gener- ation Computer Systems 90, 20-38 (2019)

    work page 2019

  7. [5]

    Samodha Pallewatta, Vassilis Kostakos, Rajkumar Buyya: Placement of Microservices-based IoT Applications in Fog Computing: A Taxonomy and Future Directions, ACM Computing Surveys (2023)

    work page 2023

  8. [6]

    Suman Karumuri, Franco Solleza, Stan Zdonik, Nesime Tatbul: Towards observability data management at scale, ACM SIGMOD Record 49(4), 18 - 23 (2021)

    work page 2021

Show all 73 references
  1. [7]

    Rudolf E Kalman: On the general theory of control systems, Proceedings First International Conference on Automatic Control, Moscow, USSR 1960) 481 - 492

    1960

  2. [8]

    Satish Narayana Srirama: A decade of research in fog computing: relevance, challenges, and future directions, Software: Practice and Experience 54(1), 3–23 (2024)

    2024

  3. [9]

    Nicolas Marie-Magdelaine, Toufik Ahmed, Gauthier Astruc-Amato: Demonstration of an observability framework for cloud native microservices, 2019 IFIP/IEEE Symposium on In- tegrated Network and Service Management (IM) 2019)

    2019

  4. [10]

    In: , ed

    Anwesha Mukherjee, Debashis De, Rajkumar Buyya: Cloud Computing Resource Manage- ment. In: , ed. by Anwesha Mukherjee, Debashis De, Rajkumar Buyya (Springer Nature Singapore 2024) pp. 17 - 37

    2024

  5. [11]

    Muhammad Usman, Simone Ferlin, Anna Brunstrom, Javid Taheri: A survey on observabil- ity of distributed edge & container-based microservices, IEEE Access (2022)

    2022

  6. [13]

    Shanhe Yi, Cheng Li, Qun Li: A Survey of Fog Computing, Proceedings of the 2015 Work- shop on Mobile Big Data - Mobidata ’15, 37 - 42 (2015)

    2015

  7. [14]

    Redowan Mahmud, Ramamohanarao Kotagiri, Rajkumar Buyya: Fog computing: A taxon- omy, survey and future directions, Internet of everything (Springer 2018) 103 - 130

    2018

  8. [15]

    Gupta, R

    Amir Vahid Dastjerdi, H. Gupta, R. N. Calheiros, S. K. Ghosh, Rajkumar Buyya: Fog Computing: Principles, architectures, and applications, Internet of Things: Principles and Paradigms, 61 - 75 (2016)

    2016

  9. [16]

    Koustabh Dolui, Soumya Kanti Datta: Comparison of edge computing implementations: Fog computing, cloudlet and mobile edge computing, GIoTS 2017 - Global Internet of Things Summit, Proceedings (2017)

    2017

  10. [17]

    Pasika Ranaweera, Anca Delia Jurcut, Madhusanka Liyanage: Survey on multi-access edge computing security and privacy, IEEE Communications Surveys & Tutorials 23(2), 1078 - 1124 (2021)

    2021

  11. [18]

    Mung Chiang, Sangtae Ha, Fulvio Risso, Tao Zhang, I Chih-Lin: Clarifying fog computing and networking: 10 questions and answers, IEEE Communications Magazine 55(4), 18 - 20 (2017)

    2017

  12. [19]

    Al-Doghman, Z

    F. Al-Doghman, Z. Chaczko, A. R. Ajayan, R. Klempous: A review on Fog Computing technology, 2016 IEEE International Conference on Systems, Man, and Cybernetics (SMC)

    2016

  13. [20]

    Joao Bachiega, Breno Gustavo Soares da Costa, Aleteia P. F. Araujo: Computational Per- spective of the Fog Node, 22nd International Conference on Internet Computing & IoT (2021)

    2021

  14. [21]

    Antonio Brogi, Stefano Forti: QoS-aware deployment of IoT applications through the fog, IEEE internet of Things Journal 4(5), 1185–1192 (2017)

    2017

  15. [22]

    Mostafa Haghi Kashani, Amir Masoud Rahmani, Nima Jafari Navimipour: Quality of service-aware approaches in fog computing, International Journal of Communication Sys- tems 33(8), e4340 (2020)

    2020

  16. [23]

    Walayat Hussain, Farookh Khadeer Hussain, Omar Khadeer Hussain: Maintaining trust in cloud computing through SLA monitoring, 2014) 690–697

    2014

  17. [24]

    Cindy Sridharan: Distributed systems observability: a guide to building robust systems (O’Reilly Media, 2018)

    2018

  18. [25]

    Suman Karumuri, Franco Solleza, Stan Zdonik, Nesime Tatbul: Cloud Observability: A MELTing Pot for Petabytes of Heterogenous Time Series., CIDR 2021)

    2021

  19. [26]

    Thesis 2021)

    Nicolas Marie-Magdelaine: Observability and resources managements in cloud-native envi- ronments Ph.D. Thesis 2021)

    2021

  20. [27]

    Benjamin H Sigelman, Luiz Andr´ e Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, Chandan Shanbhag: Dapper, a large-scale distributed systems tracing infrastructure, (2010)

    2010

  21. [28]

    Martin McGrane, Simon K Poon: A Method to Estimate High-Dimensional Synergistic Interactions: A Case Study on Information Technology Business Value, (2011) BIBLIOGRAPHY 29

    2011

  22. [30]

    Amir Vahid Dastjerdi, Rajkumar Buyya: Fog computing: Helping the Internet of Things realize its potential, Computer 49(8), 112-116 (2016)

    2016

  23. [31]

    big data

    Ibrahim Abaker Targio Hashem, Ibrar Yaqoob, Nor Badrul Anuar, Salimah Mokhtar, Ab- dullah Gani, Samee Ullah Khan: The rise of “big data” on cloud computing: Review and open research issues, Information systems 47, 98-115 (2015)

    2015

  24. [32]

    Joanna Kosi´ nska, Bartosz Bali´ s, Marek Konieczny, Maciej Malawski, S lawomir Zieli´ nski: Toward the observability of cloud-native applications: The overview of the state-of-the-art, IEEE Access 11, 73036 - 73052 (2023)

    2023

  25. [33]

    Joshua Levin, Theophilus A Benson: ViperProbe: Rethinking microservice observability with eBPF, 2020 IEEE 9th International Conference on Cloud Networking (CloudNet) 2020) 1-8

    2020

  26. [34]

    Euripides GM Petrakis, Stelios Sotiriadis, Theodoros Soultanopoulos, Pelagia Tsiachri Renta, Rajkumar Buyya, Nik Bessis: Internet of things as a service (itaas): Challenges and solutions for management of sensor data on the cloud and the fog, Internet of Things 3, 156 - 174 (2018)

    2018

  27. [35]

    Kaneez Fizza, Abhik Banerjee, Karan Mitra, Prem Prakash Jayaraman, Rajiv Ranjan, Pankesh Patel, Dimitrios Georgakopoulos: QoE in IoT: a vision, survey and future directions, Discover Internet of Things 1, 1–14 (2021)

    2021

  28. [36]

    R Babu, K Jayashree, R Abirami: Fog Computing Qos Review and Open Challenges, Re- search Anthology on Architectures, Frameworks, and Integration Strategies for Distributed and Cloud Computing (IGI Global 2021) 1147 - 1157

    2021

  29. [37]

    Radoslav Gatev: Introducing Distributed Application Runtime (Dapr)(Springer, 2021)

    2021

  30. [38]

    Albert Jonathan, Mathew Ryden, Kwangsung Oh, Abhishek Chandra, Jon Weissman: Neb- ula: Distributed edge cloud for data intensive computing, IEEE Transactions on Parallel and Distributed Systems 28(11), 3229 - 3242 (2017)

    2017

  31. [39]

    Ghofrane Fersi: Fog computing and Internet of Things in one building block: A survey and an overview of interacting technologies, Cluster Computing 24(4), 2757 - 2787 (2021)

    2021

  32. [40]

    Lukasz Kufel: Tools for distributed systems monitoring, Foundations of Computing and Decision Sciences 41(4), 237 - 260 (2016)

    2016

  33. [41]

    Mohamed Abderrahim, Meryem Ouzzif, Karine Guillouard, Jerome Francois, Adrien Lebre: A holistic monitoring service for fog/edge infrastructures: a foresight study, 2017 IEEE 5th International Conference on Future Internet of Things and Cloud (FiCloud) (IEEE 2017) 337-344

    2017

  34. [42]

    ´Alvaro Brand´ on, Mar ´ ıa S P´ erez, Jesus Montes, Alberto Sanchez: Fmone: A flexible moni- toring solution at the edge, Wireless Communications and Mobile Computing 2018 (2018) 30 BIBLIOGRAPHY

    2018

  35. [43]

    Xavi Masip, Eva Mar ´ ın, Jordi Garcia, Sergi S` anchez: Collaborative Mechanism for Hybrid Fog-Cloud Scenarios, Fog and Fogonomics: Challenges and Practices of Fog Computing, Communication, Networking, Strategy, and Economics, 7 - 60 (2020)

    2020

  36. [44]

    Xinkui Zhao, Jianwei Yin, Chen Zhi, Zuoning Chen: SimMon: a toolkit for simulation of monitoring mechanisms in cloud computing environment, Concurrency and Computation: Practice and Experience 29(1), e3832 (2017)

    2017

  37. [45]

    Breno Costa, Joao Bachiega, Leonardo Rebou¸ cas de Carvalho, Aleteia P. F. Araujo: Or- chestration in Fog Computing: A Comprehensive Survey, ACM Comput. Surv. 55(2) (jan 2022)

    2022

  38. [46]

    Prometheus: An open-source metrics management system., https://prometheus.io/ (2023)

    2023

  39. [47]

    CAdvisor, https://github.com/google/cadvisor (2024)

    2024

  40. [48]

    OpenMetrics: OpenMetrics, https://openmetrics.io/ (2024)

    2024

  41. [49]

    Filebeat: Lightweight shipper for logs., https://www.elastic.co/guide/en/beats/filebeat/ current/filebeat-overview.html (2023)

    2023

  42. [50]

    Fluentd: An open source data collector for unified logging layer, https://www.fluentd.org/ (2024)

    2024

  43. [51]

    Elastic: The ELK Stack, https://www.elastic.co/what-is/elk-stack (2023)

    2023

  44. [52]

    Elastic: Kibana - an open source data visualization tool., https://www.elastic.co/kibana (2024)

    2024

  45. [53]

    Logtash: A log data management tool., https://www.elastic.co/pt/logstash (2024)

    2024

  46. [54]

    Jaeger: Open source, end-to-end distributed tracing., https://www.jaegertracing.io/ (2023)

    2023

  47. [55]

    OpenZipkin: A distributed tracing system, https://zipkin.io/ (2023)

    2023

  48. [56]

    OpenCensus: OpenCensus, https://opencensus.io/ (2024)

    2024

  49. [57]

    OpenTracing: OpenTracing, https://github.com/opentracing/specification (2024)

    2024

  50. [58]

    OpenTelemetry: - Python Library, https://opentelemetry.io/docs/instrumentation/python/

  51. [59]

    Andre Bento, Jaime Correia, Ricardo Filipe, Filipe Araujo, Jorge Cardoso: Automated anal- ysis of distributed tracing: Challenges and research directions, Journal of Grid Computing 19(1), 1 - 15 (2021)

    2021

  52. [60]

    Influx Data: InfluxDB - An Open Source Time Series Database., https://www.influxdata.com/products/influxdb/ (2024)

    2024

  53. [61]

    QuestDB: QuestDB - An Open Source Time Series Database., https://questdb.io/ (2024)

    2024

  54. [62]

    Grafana Labs: An Open Source visualisation tool., https://grafana.com/ (2023)

    2023

  55. [63]

    Graphite, https://graphiteapp.org/ (2024)

    2024

  56. [64]

    Ammar Gharaibeh, Mohammad A Salahuddin, Sayed Jahed Hussini, Abdallah Khreishah, Issa Khalil, Mohsen Guizani, Ala Al-Fuqaha: Smart cities: A survey on data management, security, and enabling technologies, IEEE Communications Surveys & Tutorials19(4), 2456- 2501 (2017) BIBLIOGRAPHY 31

    2017

  57. [65]

    Abhik Banerjee, Breno Costa, Abdur Rahim Mohammad Forkan, Yong-Bin Kang, Felip Marti, Chris McCarthy, Hadi Ghaderi, Dimitrios Georgakopoulos, Prem Prakash Jayaraman: 5G enabled smart cities: A real-world evaluation and analysis of 5G using a pilot smart city application, Inter...

    2024

  58. [66]

    Brendan Gregg: BPF performance tools(Addison-Wesley Professional, 2019)

    2019

  59. [67]

    Francisco Neves, Ricardo Vila¸ ca, Jos´ e Pereira: Detailed black-box monitoring of distributed systems, ACM SIGAPP Applied Computing Review 21(1), 24 - 36 (2021)

    2021

  60. [68]

    Mohammadreza Rezvani, Ali Jahanshahi, Daniel Wong: Characterizing In-Kernel Observ- ability of Latency-Sensitive Request-Level Metrics with eBPF, 2024 IEEE International Sym- posium on Performance Analysis of Systems and Software (ISPASS) 2024) 24 - 35

    2024

  61. [69]

    StatsD: StatsD Protocol, https://github.com/etsy/statsd/wiki (2024)

    2024

  62. [70]

    Sean Porter: Sensu and the Art of Monitoring., https://github.com/sensu/ (2016)

    2016

  63. [71]

    Jonathan Stuart Ward, Adam Barker: Observing the clouds: a survey and taxonomy of cloud monitoring, Journal of Cloud Computing 3(1), 1 - 30 (2014)

    2014

  64. [72]

    Pedro Freire Popiolek, Karina dos Santos Machado, Odorico Machado Mendizabal: Low over- head performance monitoring for shared infrastructures, Expert Systems with Applications 171, 114558 (2021)

    2021

  65. [73]

    Andre Bridges: Monitoring and Observability for Infrastructure and Applicationsl, https://www.gartner.com/document/5486695 (2024)

    2024

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.