You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ChangeLog.txt
+7-3Lines changed: 7 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,19 @@
1
-
StatsAgg 1.2 - released 2015-xx-xx
1
+
StatsAgg 1.3 - released 2015-xx-xx
2
+
3
+
4
+
StatsAgg 1.2 - released 2015-04-27
2
5
* Performance & memory utilization improvements -- most noticeable under high load scenarios
3
-
* Added a new OpenTSDB HTTP listener. By default, it will listen on "http://statsagg-hostname:4243"
6
+
* Added a new OpenTSDB HTTP listener. By default, it will listen on "http://statsagg-hostname.com:4243"
4
7
This listener operates outside of the Tomcat container & does not have an application context.
5
8
This is now the recommended way to get metrics into OpenTSDB via HTTP. The Tomcat listener (same port/context as the WebUI) is still supported, but not recommended.
6
-
* Added support for OpenTSDB compression on metric-sending
9
+
* Added support for reading OpenTSDB metrics that were sent with gzip compression
7
10
* Added support for StatsD histograms
8
11
* Added Support for sample-rates on StatsD timers
9
12
* Tweaks to many WebUI pages
10
13
* Friendly messages when page input parameters aren't valid.
11
14
* Applied formatting to the list of email addresses in 'Notification Groups' & 'Notification Group Details'
12
15
* WebUI -- Added support for doing a search on a table based off a uri parameter. Allows immediate filtering of the table on page load. Applies to all tables.
16
+
* 'One time' alert suspensions are now allowed to suspend an alert indefinitely. Previously they were limited to 24 hours.
13
17
* Minor OpenTSDB 'send previous value' improvements
14
18
* Lowered the thread priority of alert-routine threads
* StatsPoller -- a Pearson-developed metrics collection agent for servers (to be released sometime in 2015).
93
94
* Anything that can output in Graphite, StatsD, or OpenTSDB format
94
95
@@ -101,7 +102,7 @@ Detailed information about StatsAgg's metric format support, including examples,
101
102
102
103
## Technology
103
104
* StatsAgg is a Java 1.7 based webapp. It compiles into a war file, and is intended to be deployed into Apache Tomcat 7+.
104
-
* StatsAgg uses a database for storing things like 'StatsD gauge values', alert definitions & statuses, metric group definitions, etc. The database technology can be Apache Derby Embedded, or MySQL 5.6+.
105
+
* StatsAgg uses a database for storing things like 'StatsD gauge values', alert definitions & statuses, metric group definitions, etc. The database technology can be Apache Derby Embedded or MySQL 5.6+.
105
106
* StatsAgg can run on almost any modern OS. Windows, Linux, etc.
106
107
107
108
<br>
@@ -110,7 +111,6 @@ Detailed information about StatsAgg's metric format support, including examples,
110
111
* StatsAgg only supports running in a single-server configuration.
111
112
* While this is a limitation, a lot of time/energy was put into tuning StatsAgg's performance. For *most* implementations, a single StatsAgg server should be adequate.
112
113
* A few StatsD features that are in the main StatsD program are missing in StatsAgg. Missing features include...
113
-
* histograms on timers (will be included in a future build).
114
114
* configuring StatsAgg to be a 'repeater' (you can use the official StatsD program to do this, and forward to StatsAgg).
115
115
* configuring StatsAgg to be in a 'proxy cluster' configuration (you can use the official StatsD program to do this, and forward to StatsAgg).
116
116
* outputting frequently sent metric-keys to log files.
/* Note -- this method may seem to have a contrived implementation, but the majority of the coding choices for this method were made to
303
-
achieve maximum performance. A cleaner, Calendar-only, model was originally used, but it performed 2x slower, so it was replaced with this structure. */
/* Note -- this method may seem to have a contrived implementation, but the majority of the coding choices for this method were made to
350
+
achieve maximum performance. A cleaner, Calendar-only, model was originally used, but it performed 2x slower, so it was replaced with this structure. */
/* covers the cicumstance of specifiedDateAndTime being in an active alert suspension time window, and the time window started the day before specifiedDateAndTime */
325
362
if (specifiedDateAndTime_Date.getDate() != specifiedDateAndTime_MinusDuration.getDate()) {
326
363
// gets a calendar with a date of "one day before specifiedDateAndTime's date" & alertSuspension's start-time
@@ -349,8 +386,8 @@ public static boolean isDateAndTimeInSuspensionWindow(AlertSuspension alertSuspe
349
386
/* covers the cicumstance of dealing with an alert suspension that doesn't involve an alert suspension time window that started the day before specifiedDateAndTime */
350
387
351
388
// gets a calendar with specifiedDateAndTime's date & alertSuspension's start-time
0 commit comments