im try to figure it out, why my Data form influxdb (sending using telegraf) date time not match when display to Dashboard usign Grafana, ntp already running and match in any server , client, influxdb and grafana server
thanks for any help
solved.... in each dashboard have a setting for TIME LOCAL
thanks all
Related
I am having a problem whith permissions in influx 1.8.3.
I created a new user and grant read permisions for it.
This is the user that I configured in grafana for make queries. The point of this is avoid delete data from grafana, however, If I write "Drop measurement xxx", the measuremet is dropped...
How works permissions here?
Ther is something I am missing?
A lot of thaks!
I'm developing an app on Android with Kotlin, using Firebase Real-time DB.
Is there any way to speed up sync with host DB when clients returning online from offline?
When clients go offline, they write new data in their local cache and sync with host DB when returning online.
The problem is, it takes 1～2 minutes to sync with host DB after returning to online.
I'd really appreciate if you give me a solution.
I solved!
By calling a goOffline() method, and then calling a goOnline() method, a client instantly start to sync with a host server.
Hope it will help you!!!
When all the code is running in a Google Project; performance is as expected.
However; during development, I connect my laptop to a test Google Project BigTable instance; and each query takes 2-4 seconds to run.
Its a similar response response when I trigger commands using cbt CLI commands.
Is there a known reason for this overhead? Perhaps its how auth needs to be done for external connections?
On start up I see the below logs:
Opening connection for projectId ..., instanceId ..., on data host bigtable.googleapis.com, admin host bigtableadmin.googleapis.com.
Bigtable options: BigtableOptions{dataHost=bigtable.googleapis.com, adminHost=bigtableadmin.googleapis.com, ..., appProfileId=, userAgent=hbase-1.4.1, credentialType=DefaultCredentials, port=443, dataChannelCount=32, retryOptions=RetryOptions{retriesEnabled=true, allowRetriesWithoutTimestamp=false, statusToRetryOn=[DEADLINE_EXCEEDED, UNAVAILABLE, UNAUTHENTICATED, ABORTED], initialBackoffMillis=5, maxElapsedBackoffMillis=60000, backoffMultiplier=2.0, streamingBufferSize=60, readPartialRowTimeoutMillis=60000, maxScanTimeoutRetries=3}, bulkOptions=BulkOptions{asyncMutatorCount=2, useBulkApi=true, bulkMaxKeyCount=125, bulkMaxRequestSize=1048576, autoflushMs=0, maxInflightRpcs=320, maxMemory=143183052, enableBulkMutationThrottling=false, bulkMutationRpcTargetMs=100}, callOptionsConfig=CallOptionsConfig{useTimeout=false, shortRpcTimeoutMs=60000, longRpcTimeoutMs=600000}, usePlaintextNegotiation=false}.
Refreshing the OAuth token
Are there any options I can consider; other than using the BitTable emulator? I had some trouble getting that running a while back; so must try again.
Thanks,
Brent
As Solomon said above, please open a Google Cloud support ticket to resolve this.
We're using ejabberd as our xmpp server and iphone xmppframework for client side.
The problem is when we get the offline messages the timestap that is written in the message is in actual date/time format but the timezone of the server is different than the clients time zones so at this point the things are getting messy.
We're using a same approach while querying Last Activity of a user(XEP-0012) , but in last activity xep the server returns the information as "how many seconds ago the user last logged in to server" so in this way we can apply seconds difference to our clients time and found the message delivery date/time so there is no problem in Last Activity query.
But in delayed delivery , ejabberd sends an exact date and time value and clients confuses about the conversion(Date and time of each client may be very different from each others)
Does anyone know how can we fix that problem? Is there any way to configure ejabberd to return "seconds passed information" until offline message send ?
By the way we're using latest ejabberd version.
Thanks
XEP-0091 (Legacy Delayed Delivery) says:
The timezone is be understood as UTC.
So you need to convert the time from UTC to the local time of the client in order to get the correct result.
The newer specification, XEP-0203 (Delayed Delivery) also says:
[...] MUST be expressed in UTC
Our experiments have shown that GMail does not use UTC for the internal dates in its mailstore. Anyone know what offset it uses? We've narrowed it to between 3 and 7 hours behind UTC (exclusive), and we could figure it out with further experimentation, but maybe someone knows off-hand. UID SEARCH and the like aren't very accurate if you are assuming UTC and it's not the case. :-)
Further, we're wondering if it's consistent regardless of where you're connecting to gmail in the world.
Update: the first test showed UTC-4 or UTC-5, and a second test I did (sending hourly emails) revealed my account to be UTC-7. We're wondering if it's set when you register depending on your source IP (I also registered an account with a UTC-10 timezone and the internal store was still UTC-7. And changing your account timezone later doesn't change the internal store date an IMAP client sees, wisely, I would think).
I had written a python IMAP lib client and confirmed that the Gmail timezone is UTC-07:00 and I have confirmed it over and over again. So, any search results that you obtain (more precisely the after: startDate and before: endDate query) are shifted by that much amount according to your local timezone. This is because the mailstore uses the local time according to the sender SMTP server, which in case of gmail happens to be at UTC-07:00.