Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Pierre Rust
    @PierreRust
    in json.rs :
    consumption: ((*value as f32
                            / (host_time * procfs::ticks_per_second().unwrap() as f32))
                            * host_power as f32),
    20 replies
    bpetit
    @bpetit
    you can see an example in main, in riemann or prometheus. Here it is: https://github.com/hubblo-org/scaphandre/blob/main/src/exporters/riemann.rs#L152
    the functions get_*_metrics
    Pierre Rust
    @PierreRust
    ok, that's a change that is not yet merged in the json exporter PR, is that right ?
    bpetit
    @bpetit
    it is merged in main, but this branch is not up to date yes
    Pierre Rust
    @PierreRust
    Hello, I'm looking right now at the code for the MetricGenerator
    I would like to generate process metrics in the json exporter the same way it is done in other exporters, i.e. using the MetricGenerator, but the Metric struct does not include the timestamp.
    And when looking at the Topology, is seems that the timestamp for the host consumption is set to the point when record are generated (refresh_record) which is not the time when the measurement are actually read , is there a reason for that ?
    bpetit
    @bpetit

    Hi, great !

    I didn't remember that. We should move it closer to the actual measurement. Regarding the Metric struct, it's been made after the json/timestamp PR and we didn't catch up yet.
    Feel free to propose changes for both topics if you have the time.

    So no good reason for that no.
    Pierre Rust
    @PierreRust
    ok, I just added some comments on the PR
    BTW, do you know how I can push "cleanly" to the current PR #75 ?
    3 replies
    Pierre Rust
    @PierreRust
    Hi all
    I'm still trying to see how we could factorize metric generation into a single place
    To make sure all exporters actually export the same data. Currently the MetricGenerator is supposed to to that but we're not really there yet : the gen_all_metrics is only used by the prometheus exporter, sdout json and riemann exporters all implement their own logic for process consumption (which is for me the most important metric)
    Pierre Rust
    @PierreRust
    and actually, process metrics are computer in Topology ...
    well, I'm not sure how to make that cleaner (and safer, especially !), any ideas ?
    bpetit
    @bpetit

    Hi,

    That's a good point, we needed some specific behavior for the riemann exporter so we didn't used the generic function. We should definitely find a cleaner way to do that.

    The power consumption calculation for each process could be easily moved to MetricGenerator though, as it only requires to have access to both the topology and ProcessTracker.

    I need to have a closer look to add some thoughts to the discussion about the gen_process_metrics function.
    Pierre Rust
    @PierreRust
    Hi. when looking into that, there are maybe some other refactoring needed.
    for example to implement a msr or perf_event rapl reading, these method are currently in the CPUSocket, etc. implementation, which make it hard to provide several alternatives
    René Ribaud
    @uggla
    Hello, by the way I will probably introduce a new sensor for GPU. So I may change a couple of stuff around that in order to allow 2 kind of sensors.
    Maybe I should wait you finished with #75 ? Thanks to advice on this.
    René Ribaud
    @uggla
    @bpetit , I missed that : That's a good point, we needed some specific behavior for the riemann exporter so we didn't used the generic function. We should definitely find a cleaner way to do that.
    René Ribaud
    @uggla
    This confused me as I think metric gen method can be used here.
    René Ribaud
    @uggla
    @bpetit Anyway, I missed that during our review, I'll propose an MR improving this instead of talking. :)
    René Ribaud
    @uggla
    1 reply
    hurdman
    @hurdman:matrix.org
    [m]
    Hello o/
    bpetit
    @bpetit
    Hey ! :)
    Joel Takvorian
    @jotak
    Hello there!
    I'm planning to try scaphandre on kubernetes, on an aws ec2 instance, but I have some doubts ... has anyone already done that, is it supposed to work?
    especially, I'm not sure if it's VMs hence if I would run into these troubles : https://hubblo-org.github.io/scaphandre-documentation/how-to_guides/propagate-metrics-hypervisor-to-vm_qemu-kvm.html
    René Ribaud
    @uggla
    Hi @jotak !
    René Ribaud
    @uggla
    Currently we need to have access to the power repl driver (/sys/devices/virual/powercap) to calculate consumption. On a vm you need to do the procedure you highlighted above in order to know the consumption on a per vm basis.
    Unfortunately, in order to do the procedure you need access to the hypervisor and this is not the case on cloud providers.
    We have an issue opened hubblo-org/scaphandre#25 to estimate power consumption as a fall back plan when we don't have access to the sensors. But this is not a simple problem so far from being done.
    bpetit
    @bpetit

    Hi there !

    I felt like we had many topics on going and one could be a bit lost about what's going on and what PR should be merged first etc.

    I wrote a quick "monthly report" here

    I encourage you to discuss on that thread for everything related. It seems to me this is much more readable than the chat on the long term.

    please also tell me if this adds value or not, and why. I'd like to make the management of the project more transparent.

    bpetit
    @bpetit
    :point_up: MONTHLY REPORT 06/2021 :point_up:
    Samuel Langlois
    @slanglois
    Hi there! Newbie here… I love the project, and would love to help. However, I can't do much on the technical side, that's way beyond me. But if that's okay, I'll have a look at proofreading the documentation. Also, I think I can make the Readme more "snappy"… See you in a pull request soon ;-)
    bpetit
    @bpetit
    Hi @slanglois ! That's great to hear ! See you in a pull request then ! :)
    bpetit
    @bpetit

    Hi !

    Working on #109 I've changed a bit the way MetricGenerator can be used. It now owns the Topology struct (it held a reference previously). It makes easier having the MetricGenerator struct instantiated outside of the loop of most exporters and thus optimize performances (holding counters for instance to create some cache-like mecanisms). My case was with prometheus exporter, when using --containers, to not query the docker socket to often.

    Please have a look if your are interested. A company interested in the feature (extra labels for processes metrics when in a docker container) will test it before I merge. Feel free to tell me your thoughts about this (and the feature) in the mean time.

    cc @uggla
    olivier de Meringo
    @demeringo

    Hi !
    Do you use scaphandre in CI ?
    I would like to measure the energy consumed by a test suite to get a kind of power score for different iterations of an application code.

    My naive approach is the following:

    • use scaphandre container customized (with the application under test + test suite)
    • start scaph (json export) for a fixed time
    • run the test
    ... and retrieve the json restults as CI artefacts...
    But there surely must be a better way, how do you do this ?
    olivier de Meringo
    @demeringo
    This is a micro project where I use gitlabci + scaph (and simulate a test run with stress-ng).
    The gitlab runner is a custom runner on a Linux laptop.
    bpetit
    @bpetit

    Hi @demeringo !

    I'd say you could store metrics in a TSDB and export graphs for a given time window through grafana API for example.
    I don't have a detailed procedure available but it seems completely possible.

    Depends on what you want to do with the data afterwards
    René Ribaud
    @uggla
    @demeringo , interesting use case. I think Riemann is a good candidate for this ! Riemann is working with a push model. So you can imagine the following pipeline: (ci image with scaphandre) --> (Riemann) --> (Influx DB or ES)
    Then you can see live data in the Riemann dashboard and TS data (history) in influx with Grafana or ES with (Grafana ou Kibana)
    René Ribaud
    @uggla
    By the way I could slightly modify Scaphandre to add metadata (keys/values) to Riemann, so your scaph client could send these metadata (build id, etc...) alongside with power/process values.