Dieterbe ( Dieter Plaetinck )

We aim to work with what monitoring systems are actually out there, and build on the install base that Prometheus and its format have rather than inventing brand new things that no one currently supports or has experience with. For what you'd suggest we'd have to get the capability to handled this added to all monitoring systems out these including Prometheus, Graphite, and the various SaaS vendors for the sake of what is as far as we're aware an extremely rare use case. Put another way it doesn't make sense to break the ability to calculate the average for the ~99.9% of users where it is a counter and observations are always positive for the sake of the ~0.1% of uses where there might be a case for negative observations.

If you need this, I'd suggest having two counters - one for the ups and one for the downs. It is not an aim of OpenMetrics to have a first-class metric type for every possible use case, rather allowing users to combine Counters/Gauges as needed. There's no position metric type either for example, as two gauges for longitude and latitude can handle that.

belm0

comment created time in 3 days

issue commentOpenObservability/OpenMetrics

I read https://github.com/OpenObservability/OpenMetrics/issues/64

It's straightforward to agree that _mean is not a useful metric.

But that is besides the point of _sum being a gauge or counter. If it's a gauge, there is no precision issue, and together with _count it's possible to compute the average at every point it time.

belm0

comment created time in 3 days

issue closedOpenObservability/OpenMetrics

why:

histograms and averages supporting negative observations are desirable
it should be possible to trivially derive mean from a Histogram

Where is the documented rationale for Sum being of type counter rather than a gauge? Not supporting negative observations is a significant loss, so it would have to be very compelling.

If Sum is not a gauge, as a user I'm forced to add my own gauge sum metric along side every Histogram and Summary instance.

Semantically, Sum, and buckets values are counters so MUST NOT be NaN or negative. Negative threshold buckets MAY be used, but then the Histogram MetricPoint MUST NOT contain a sum value as it would no longer be a counter semantically.

closed time in 3 days

belm0

issue commentOpenObservability/OpenMetrics

This behaviour has been discussed at length, and this is an explicit design decision. Allowing counters to go backwards would break all existing monitoring systems we're aware of, as none of them would then be able to calculate the correct rate for the _sum and thus would not be able to calculate any rates or subsequently averages.

Closing as duplicate of #143.

in Python prometheus_client I found there is a "gaugehistogram" type added

This is not related to your question. Gcount does not monotonically increase, it is a gauge which can go up or down from scrape to scrape.

belm0

comment created time in 3 days

issue commentOpenObservability/OpenMetrics

in Python prometheus_client I found there is a "gaugehistogram" type added

it adds incompatible _gcount an _gsum child metrics
why _gcount? The count is still monotonically increasing.
why make two types and make all levels of prometheus (client, server, queries, etc.) care about it?
it doesn't address Summary, which should also support negative observations

belm0

comment created time in 4 days

issue openedOpenObservability/OpenMetrics

why:

histograms and averages supporting negative observations are desirable
it should be possible to trivially derive mean from a Histogram

Where is the documented rationale for Sum being of type counter rather than a gauge? Not supporting negative observations is a significant loss, so it would have to be very compelling.

If Sum is not a gauge, as a user I'm forced to add my own gauge sum metric along side every Histogram and Summary instance.

Semantically, Sum, and buckets values are counters so MUST NOT be NaN or negative. Negative threshold buckets MAY be used, but then the Histogram MetricPoint MUST NOT contain a sum value as it would no longer be a counter semantically.

created time in 4 days

startedbenbjohnson/litestream

started time in 4 days

pull request commentnaggie/dstask

Thanks both.

botto

comment created time in 6 days

push eventnaggie/dstask

commit sha 380c9e87ae272cff0e9167645486e37e87492a49

Tweak LoadTask to not exit on error Added a new MustLoadTask that uses LoadTask, but exits if there is an error returned.

commit sha 5eb0d19d89e27e09f61f1a0a0a9d9e0cee58021e

Pass tasks by ref Change tasks to be passed by ref, this means we can return `nil` instead of a `Task{}`

commit sha 7bd22fffbd491c60f39d75748c329bc3702870f3

Split out MustGitCommit in to GitCommit This lets us run git commands without the process dying

commit sha fda0b6e92e2ffa02d5230c5279c5240aad2949bc

Added `UpdateTask` which returns error

commit sha 675b77baee29cb42e5269206dc022e9be95e3981

Added `GetByID` which returns an error

commit sha c02dd0ff7336d113586a7286f1031d4190298400

Revert to passing in the whole task This change reverts to passing in the whole task and not a ref to it. This is to keep consistency with the rest of the code base

commit sha 69de1ab3a8a45d1089c75d7334c41df5bbd83cb6

Don't error out on no changes

Callan Bryant

commit sha 92869cab39b8536cfb7b5ba82c84b6aa03a6da57

Merge pull request #123 from botto/lib-tweaks Library tweaks for using dstask in API

Manual deploy JSON config file downloads not working

push time in 6 days

PR merged naggie/dstask

Library tweaks for using dstask in API

As I'm building out the HTTP API for dstask I'm doing some tweaks to the dstask codebase so it's more library like in places where there are some hard ExitFail.

I'll try and keep each tweak to a single commit so this PR can be more easily reviewed later.

For now I'm going to put this in a draft state and once the HTTP api is working with majority of features (or this PR starts getting quite big) I'll change it to a proper PR

+69 -27

7 commit in botto/dstask/tree/lib-tweaks naggie/dstask/tree/master

5 comments

3 changed files

botto

pr closed time in 6 days

issue closedraintank/legacy-kubernetes-app

When creating a new cluster, after defining the the cluster and graphite settings and saving, when trying to download the config files for a manual deploy, the buttons do nothing. Looking at the trace in the browser I see this error:

angular.js:14700 TypeError: wnd.saveAs is not a function
    at ClusterConfigCtrl.saveToFile (clusterConfig.js:117)
    at ClusterConfigCtrl.saveConfigMapToFile (clusterConfig.js:98)
    at fn (eval at compile (angular.js:15551), <anonymous>:4:181)
    at i (angular.js:27341)
    at t.$eval (angular.js:18423)
    at t.$apply (angular.js:18523)
    at HTMLButtonElement.<anonymous> (angular.js:27346)
    at HTMLButtonElement.dispatch (jquery.js:5206)
    at HTMLButtonElement.g.handle (jquery.js:5014)

closed time in 6 days

alemsh

PR opened naggie/dstask

#128 inline template notes

Closes #128

+95 -0

3 commit in cgardner/dstask/tree/128-inline-template-notes naggie/dstask/tree/master

0 comment

3 changed files

pr created time in 7 days

startedliamg/traitor

started time in 7 days

Pull request review commentnaggie/dstask

Urgency

+# Urgency++Urgency is pretty primitive at the moment. It should only affect tasks that are+not resolved.++It takes the Task's priority as a Fibonacci (Low = 1, Critical = 5) and an applies a multiplier (5).

This was a complete guess to start out. I left the implementation mostly as a way to start the conversation about what the weights should be for everything.

cgardner

comment created time in 7 days

Pull request review commentnaggie/dstask

Urgency

+# Urgency++Urgency is pretty primitive at the moment. It should only affect tasks that are+not resolved.++It takes the Task's priority as a Fibonacci (Low = 1, Critical = 5) and an applies a multiplier (5).++If the status is active, it adds 5.++If a project or tag is applied, add 3 for each.++It also multiplies the age of the task by 0.05 and adds that to the urgency.

Priority is taken into account. After adding urgency, it would sort by priority > urgency > created.

I didn't do anything with due date because I understood it wasn't implemented, but it shouldn't be too hard to add that.

cgardner

comment created time in 7 days

Pull request review commentnaggie/dstask

Urgency

+# Urgency++Urgency is pretty primitive at the moment. It should only affect tasks that are+not resolved.++It takes the Task's priority as a Fibonacci (Low = 1, Critical = 5) and an applies a multiplier (5).

Agreed, and the reasoning behind it doesn't come naturally.

I suggest an approach of identifying then addressing individual problems that the current sorting method has; note that if the basic method is good 95% it's probably a good solution

cgardner

comment created time in 7 days

issue commentnaggie/dstask

Use $XDG_CONFIG_HOME for config dir

https://github.com/adrg/xdg#xdg-base-directory > the dirs listed here for unix seems fine. Do we have any windows/mac users amongst us who can "sign off" on these paths? Note this lib uses ~/Library/Preferences which seems a bit contentious. But I'ld like to just pick a library and go forward with it. --

@Dieterbe Not anymore :). The library now suggests writing files relative to the ~/Library/Application Support directory, if XDG_CONFIG_HOME is not set. However, it can find config files relative to ~/Library/Preferences, /Library/Application Support and /Library/Preferences as well.

joereynolds

comment created time in 7 days

issue commentOpenObservability/OpenMetrics

Clarify if Summary can have negative values

I think the wording in the draft is not strong enough.

It can be easily read in a way that Sum would follow conter semantics if all of the following is true:

Sum is not NaN.
Sum is not negative.
There are no negative bucket thresholds in a Histogram and no negative quantile values in a Summary.

However, you can easily construct situations where all of the above is true but Sum does not follow counter semantics.

It would be much clearer to say something along the lines "Event measurement MUST NOT be negative if Sum is present."

I commented that in the draft before, but the comment got resolved, so I assumed the current wording is deliberate, but I still don't understand how that can be.

bogdandrutu

comment created time in 7 days

Pull request review commentnaggie/dstask

 func MustRunGitCmd(repoPath string, args ...string) { 	} } -// MustGitCommit stages changes in the dstask repository and commits them. If-// any error is encountered, the program exits.+// MustGitCommit is like GitCommit, except if any error is+// encountered, the program exits. func MustGitCommit(repoPath, format string, a ...interface{}) { 	msg := fmt.Sprintf(format, a...) -	// git add all changed/created files-	// could optimise this to be given an explicit list of-	// added/modified/deleted files -- only if slow. 	fmt.Printf("\n%s\n", msg) 	fmt.Printf("\033[38;5;245m") +	if err := GitCommit(repoPath, format, a...); err != nil {+		ExitFail("error: %s", err)+	}++	fmt.Printf("\033[0m")+}++// GitCommit stages changes in the dstask repository and commits them.+func GitCommit(repoPath, format string, a ...interface{}) error {+	msg := fmt.Sprintf(format, a...)+ 	// needed before add cmd, see diff-index command-	bins, _ := ioutil.ReadDir(path.Join(repoPath, ".git/objects"))+	bins, err := ioutil.ReadDir(path.Join(repoPath, ".git/objects"))+	if err != nil {+		return fmt.Errorf("failed to run git commit: %s", err)+	} 	brandNew := len(bins) <= 2 +	// git add all changed/created files+	// could optimise this to be given an explicit list of+	// added/modified/deleted files -- only if slow. 	// tell git to stage (all) changes-	MustRunGitCmd(repoPath, "add", ".")+	if err = RunGitCmd(repoPath, "add", "."); err != nil {+		return fmt.Errorf("failed to add changes to repo: %s", err)+	}

Just checking @Dieterbe your referring to the no changes detect right?

botto

comment created time in 8 days

Pull request review commentnaggie/dstask

 func MustRunGitCmd(repoPath string, args ...string) { 	} } -// MustGitCommit stages changes in the dstask repository and commits them. If-// any error is encountered, the program exits.+// MustGitCommit is like GitCommit, except if any error is+// encountered, the program exits. func MustGitCommit(repoPath, format string, a ...interface{}) { 	msg := fmt.Sprintf(format, a...) -	// git add all changed/created files-	// could optimise this to be given an explicit list of-	// added/modified/deleted files -- only if slow. 	fmt.Printf("\n%s\n", msg) 	fmt.Printf("\033[38;5;245m") +	if err := GitCommit(repoPath, format, a...); err != nil {+		ExitFail("error: %s", err)+	}++	fmt.Printf("\033[0m")+}++// GitCommit stages changes in the dstask repository and commits them.+func GitCommit(repoPath, format string, a ...interface{}) error {+	msg := fmt.Sprintf(format, a...)+ 	// needed before add cmd, see diff-index command-	bins, _ := ioutil.ReadDir(path.Join(repoPath, ".git/objects"))+	bins, err := ioutil.ReadDir(path.Join(repoPath, ".git/objects"))+	if err != nil {+		return fmt.Errorf("failed to run git commit: %s", err)+	} 	brandNew := len(bins) <= 2 +	// git add all changed/created files+	// could optimise this to be given an explicit list of+	// added/modified/deleted files -- only if slow. 	// tell git to stage (all) changes-	MustRunGitCmd(repoPath, "add", ".")+	if err = RunGitCmd(repoPath, "add", "."); err != nil {+		return fmt.Errorf("failed to add changes to repo: %s", err)+	}

Yeah, this is fine from a pragmatic standpoint, and nothing to do with being a purist. Remember we are trying to make it more like a library so it can be used in applications outside the CLI

botto

comment created time in 8 days

Pull request review commentnaggie/dstask

http://mattn.github.io/go-sqlite3

 func MustRunGitCmd(repoPath string, args ...string) { 	} } -// MustGitCommit stages changes in the dstask repository and commits them. If-// any error is encountered, the program exits.+// MustGitCommit is like GitCommit, except if any error is+// encountered, the program exits. func MustGitCommit(repoPath, format string, a ...interface{}) { 	msg := fmt.Sprintf(format, a...) -	// git add all changed/created files-	// could optimise this to be given an explicit list of-	// added/modified/deleted files -- only if slow. 	fmt.Printf("\n%s\n", msg) 	fmt.Printf("\033[38;5;245m") +	if err := GitCommit(repoPath, format, a...); err != nil {+		ExitFail("error: %s", err)+	}++	fmt.Printf("\033[0m")+}++// GitCommit stages changes in the dstask repository and commits them.+func GitCommit(repoPath, format string, a ...interface{}) error {+	msg := fmt.Sprintf(format, a...)+ 	// needed before add cmd, see diff-index command-	bins, _ := ioutil.ReadDir(path.Join(repoPath, ".git/objects"))+	bins, err := ioutil.ReadDir(path.Join(repoPath, ".git/objects"))+	if err != nil {+		return fmt.Errorf("failed to run git commit: %s", err)+	} 	brandNew := len(bins) <= 2 +	// git add all changed/created files+	// could optimise this to be given an explicit list of+	// added/modified/deleted files -- only if slow. 	// tell git to stage (all) changes-	MustRunGitCmd(repoPath, "add", ".")+	if err = RunGitCmd(repoPath, "add", "."); err != nil {+		return fmt.Errorf("failed to add changes to repo: %s", err)+	}

I agree having it as an error probably isn't correct, but currently we have no facility for status returned if that makes sense. Just outputting to stdout isn't something a lib should do so. I guess we could just return silently?

botto

comment created time in 9 days

fork otoolep/go-sqlite3

sqlite3 driver for go using database/sql

mattn/go-sqlite3 otoolep/go-sqlite3

fork in 9 days

pull request commentnaggie/dstask