Dev Meetings

Dev Meetings

 

Usually, we have bi-weekly developer meetings. The specific dates and instructions on how to join are listed on the Meetings Home page. We recommend subscribing to Kieker's calendar.


Check ticket status before the meeting and add relevant topics

The dev meetings minutes are now moved to https://github.com/kieker-monitoring/kieker/wiki/Kieker-Dev-Meetings-2024

2024-07-03

  • Switch to github for the ticket system

    • @Reiner Jung has created a backup of the tickets and will send them to Shinhyung.

  • Cloudprofiler: Shinhyung discusses running it with MooBench

  • What to do with the content of Confluence?

    • Passwords got to an encrypted keypass file and then onto a github private repository

    • Release documentation will be moved to the readthedocs documentation

    • Meetings minutes will be moved to GitHub wiki

  • Release preparation 2.0.0

2024-06-05

2024-05-29

2024-05-17

2024-04-24

2024-04-10

2024-03-27

2024-02-21

  • CI / CD: Jenkins is accesible again, move process to GH actions if manpower is available

  • Instrumentation technologies

    • Buildtime instrumentation is also implemented currently → Compare performance and probably leave it as option in the code

    • Meeting for paper at next Kieker dev meeting (either camera ready planning or QRS resubmission)

  • Disruptor: Not needed for current MooBench measurements, and it would require a bigger refactoring (creation of onXRecord for each record in WriterController); therefore, we don’t do it for now (even if it would reduce GC activity)

  • 1.15.5 release is required to have a stable version of Kieker that is compatible with Java 21 (currently, AspectJ is not compatible to Java 21)

2024-02-14

2024-01-24

2024-01-10

2023-12-13

2023-11-29

  • KIEKER-1933: Reiner resolves merge conflicts, afterwards David merges the PR

    • OPAD, extension-kafka and extension-cassandra: Don’t create bundle for now, if somebody starts using it add it

    • Reiner will create example bundle

    • resource-monitor: What is it? → Ask @Andre van Hoorn

  • Current approach with Brunel: Monitor https://github.com/idugalic/micro-company (With spring - we should check the spring example and create a better documentation sometimes)

  • Research idea: Support DiSL probe and create kieker-disl-jar, and evaluate it on some bigger project

    • Two requirements on project: Scala / Java or Kotlin / Java mixed, some workload definition for measurement

    • Adaptive Monitoring (Compare SSP inspectIT Stuttgart?)

2023-11-15

2023-11-06

2023-10-09

  • TeaStore debugging

    • No results so far

  • eclipse project debugging

    • Solution is to exclude test jars which are included twice from projects from eclipse dependencies (https://github.com/eclipse/buildship/issues/1266 )

    • This works fine for Ubuntu; for Fedora, the testImplementation 'de.cau.cs.se.teetime:teetime:3.1.0:test' dependency is not recognized correctly

2023-09-22

  • To discuss:

  • TeaStore debugging

    • TrackingFilter seems like TeaStore needs OperationExecutionRecord (kieker.monitoring.probe.aspectj.operationExecution.OperationExecutionAspectFull)

    • With OperationExecutionRecord: Traces are considered invalid, even though they are valid (Caused by: kieker.tools.trace.analysis.filter.traceReconstruction.InvalidTraceException: First execution must have ess 0 (found 1))

    • Minimal example with only one previously broken trace id works

    • Ideas:

      • Combine two traces, including a broken one; Afterwards incrementally increase number of traces

      • Ask Reiner for results of last debugging session (What was wrong in Filter?)

2023-09-12

  • To discuss:

    • Why does MooBenchs default instrumentation create different record types (OperationExecutionRecord, ApplicationTraceMetadata, BeforeOperationEvent and AfterOperationEvent)? Shouldn’t Before/AfterOperationEvent be sufficient? Instrumentation is kieker.monitoring.probe.aspectj.flow.operationExecution.FullInstrumentation

    • Is it right that MooBenchs default instrumentation does not create empty constructor call data?

    • → Yes, its intended; flow.operationExecution does not work in Java 17+ (https://stackoverflow.com/questions/70411097/instrument-java-17-with-aspectj ); therefore, we need to restructure all the records

    • Separation of Before/After Records -> David creates ticket

  • MooBench generally works again after fix, inspectIT needs fix → @David Georg Reichelt contacts Novatec

  • Thesis -> https://kieker-monitoring.atlassian.net/wiki/spaces/IDEAS/pages/24215606 -> @Andre van Hoorn checks thesis

  • Logreplyer on TeaStore data still does not work on bigger traces; discuss next time

2023-08-22

2023-07-31

  • Who will maintain Jenkins builds in future? Matthias was asking and we should find an idea to address this.

    • Somebody from Kiel? Otherwise Andre and David

  • MooBench No Logging / Binary Writer examination paper:

    • Data set does contain not-warmed up data → fix later

    • DumpQueue solves the problem

2023-07-17

2023-07-04

2023-06-20

  • OSHI is very outdated and should be updated: https://kieker-monitoring.atlassian.net/browse/KIEKER-1963

  • DiSL waiting for response

  • No Logging / Binary Writer Examination

    • First PDF and experimental results existing: https://gist.github.com/DaGeRe/c7159297bad4bd13fb556dcf696d0699

    • Check without optimization in JVM

    • perf → measure context switches

    • Measure dummy loop (David) and queue (Reiner) separately

    • Ideas for implications:

      • Try other queue

      • Callibration of dummy loops to reduce context switches

      • Check method time increase

      • Processor Pinning

      • Try other JVM

    • Related work

      • MooBench + Benchmark Design

      • Benchmark Callibration

    • Runtime Environment

      • i7-6700 → Uni Leipzig

      • Raspberry Pi?

      • Java 11 / 17?

2023-06-06

2023-05-23

2023-05-09

2023-04-26

  • Reiner und Thomas need to fix their calendar issues

  • Discussed MooBench results. Question:

    • Why Binary TCP for Kieker faster than no logging?

    • Similar inconsistency for inspectIT; David to contact Tobi A.

2023-04-04

2023-03-07

2023-02-21

2023-02-07

  • @David Georg Reichelt’s Kieker talk at Chemnitz Linuxtage accepted. Event will be on March 11, 2023. 45 minutes talk.

    • @Reiner Jung to provide input from OceanDSL tools, e.g., visualization of the architecture model

    • @David Georg Reichelt provides TeaStore logs to @Reiner Jung

  • @David Georg Reichelt presents updates to MooBench

  • To keep on the Kieker (radar): tutorial, e.g., ECSA 2023.

2023-01-25

  • General idea: Probably in the future rebase and merge instead regular merge? (from the last 1000 commits, 149 are merge commits: git log --oneline | head -n 1000 | grep "Merge pull" | wc -l)

    • For a set of commits with smaller changes: rebase or squash

    • For merging back release branches, merge request

  • FullInstrumentation does not work with Java 17: https://kieker-monitoring.atlassian.net/browse/KIEKER-1947 we either should to refactor it or to remove it

    • Possible replacemenet: https://bytebuddy.net

  • Pending TODOs

    • Merge RC back to master @David Georg Reichelt

    • Java records for monitoring records @Holger Knoche

2023-1-10

  • Release 2.0.0 ticket selection and todo list

  • @Holger Knoche suggested new record solution https://kieker-monitoring.atlassian.net/browse/KIEKER-1935

    • We need an architecture/API description for this in the documentation.

    • We need a generator for records and factory for this new type of records.

    • Summary:

      • Nice idea

      • Record keyword supported >= Java 14 but not an issue as the generic factory has no dependency to record.

        • @Holger Knoche to check whether there are features for reflection that do need Java >8.

      • Would be nice to get into the Kieker core as an alternative to define records.

      • @Holger Knoche Prepares a new pull request.

  • Perspective: rename master branch into main branch. https://kieker-monitoring.atlassian.net/browse/KIEKER-1942

    • In progress by David and Reiner. Pending issue

  • TeaStore: Monitoring basically works (requires setting IP and deactivating firewall): https://github.com/DescartesResearch/TeaStore/issues/236

    • David to merge multiple directories distributed traces (folders) and report in the next meeting.

2022-12-20

2022-11-29

  • @Andre van Hoorn will move the Kieker/resources repo from Kiel to GitHub (as a private repo)

  • Tutorial: Create a folder in the repository for the tutorial; we’ll create the proposal document in there.

  • Perspective: rename master branch into main branch. https://kieker-monitoring.atlassian.net/browse/KIEKER-1942

  • Merge back 1.15.2 to master. In progress by @David Georg Reichelt

2022-11-04

  • Kieker SSP meeting 7.11. 16:00-18:00 (get-together 15:30!) hybrid at Vector Informatik GmbH in Stuttgart Weilimdorf, Holderäckerstraße 36, 70499 Stuttgart.

  • Kieker developer meeting agenda

    • ICPE tutorial:

    • Chemnitzer Linuxtage (David): 1 hour talk

  • Items for report at SSP @Reiner Jung @Wilhelm Hasselbring @David Georg Reichelt @Thomas F. Düllmann: Please complete

    • Research activities/projects in the (wider) Kieker scope:

      • Performance monitoring and analysis of data-intensive systems, particularly based on Python+TensorFlow

      • SPEC RG: local performance models (working with some benchmark systems and extracted architectures)

      • dqualizer: domain-based analysis of runtime quality attributes, e.g., including domain-based monitoring / Dispel

      • Kiel: Dynamic analysis of ocean models? Refer to presentation

      • Peass: Usage of Kieker for architecture recovery and root cause analysis → GeoMap industry case study will be presented in this SSP, which uses Kieker

    • Technologies/Features:

      • Kieker for Python: Refer to presentation and paper (presentation by Serafim, Instrumenting Python with Kieker)

      • Kieker for Fortran: Refer to presentation and paper (presentation by Reiner, Architecture Recovery from Fortran Code with Kieker)

    • Development process and environment:

      • Accelerated release process with minor versions (semantic versioning)

      • MooBench updates: https://kieker-monitoring.net/performance-benchmarks/

        • Performance benchmarks were updated to the current Kieker version and OpenTelemetry and inspectIT (last year)

        • Continuous execution of benchmarks has been automated (again) (This year)

        • Also for Python

        • Planned for C/Fortran/C++

    • Releases:

      • Kieker 1.15.2?

        • Change in release cycle: Bugfix releases and releases fixing security problems in dependencies will be published more often in the future

        • Requires automated release process (instead manual upload to sonatype)

        • Currently, finalizing of release process adaption happens

        • Build process uses only maven/gradle dependencies

      • Kieker 2.0.0

        • Finalized integration of TeeTime-based stages

        • Naming conventions for stages

          • Stage processing, data manipulation

          • Filter filters events (Kieker events or any other data object passed between stages)

          • Sink for stages that store data

          • Source for stages that read, load or receive data

        • Refactoring to support a topic-based package structure instead of a technical motivated structure, i.e,

          • architecture

            • adaptation

            • dependency

            • metrics (metrics for architecture evaluation)

            • recovery (architecture recovery)

            • repository (architecture model repository)

            • trace (architecture based trace analysis)

          • behavior (user behavior analysis)

          • generic

          • statistics

        • New facilities to observe and analyze user behavior based on graph clustering algorithms

        • Architecture model comes now with a model repository and stages processing these repositories

        • Architecture model supports interfaces and dataflow (beta)

        • As many classes have been moved, we provide a complete list of moved classes for migration to the new version

 

 

 

2022-10-14

  • TODO: What happened with release wiki page: https://kieker-monitoring.atlassian.net/wiki/spaces/DEV/pages/5865697

  • @David Georg Reichelt is debugging the publish and sign process locally to indentify the issues with our current setup

    • Use modified Jenkinsfile in case the issue is only on Jenkins

  • How about a 2.0.0 release?

  • 3.11.2022 10:00 next online Kieker meeting

2022-10-07

  • Submit a tutorial to ICPE 2023 - deadline Jan 22, 2023

  • Next meeting 14.10. 8:30

  • Issues with release publishing due to missing keys

2022-09-23

  • Make release process transferable to other people to eliminate bottleneck

  • Make 1.15.2 release (release date 30.9.2022)

  • Set a date for the 2.0.0 release (release date 20.10.2022)

  • We need a concept for dependency updates, currently we have a none

    • Use dependabot

2022-09-02

  • New MooBench page and benchmark setup

    • Change file names to be more verbose (done)

    • First description for Kieker Java and Python @Reiner Jung (done)

    • Then @David Georg Reichelt for Telemetry and inspectIT

  • 1.15.2 Release ready, must be release @Andre van Hoorn

  • Kieker 4 Python development / paper

  • Activate Dependabot for Kieker

  • Live Demo should move to Kiel or HH @Reiner Jung will try to set this up, support @Thomas F. Düllmann

2022-07-29

  • Kieker 4 python: Development ongoing

  • Kieker 1.15.2 Release Candidate: Waiting for release → Mail to Reiner

  • MooBench: Reiner is updating everything for visualization update

    • André and Reiner fix all the bugs

  • Thomas is available on August 11. and 12, David is only available on August 11 → Move meeting to 11th? @Reiner Jung

2022-07-15

  • Please review the package structure layed out in branch and the corresponding ticket https://kieker-monitoring.atlassian.net/browse/KIEKER-1903

    • The revision must check whether the location of the classes make sense and which classes must be moved (again)

    • We need someone to look at the structure and it cannot be @Reiner Jung who created the current package structure

    • We need a definite date to when this review must be finished. There are quite some depending tickets that require this to be solved.