Firebase first_open event has become slow since the last week. Firebase says that "conversion events are uploaded immediately by the SDK in order to make them actionable more quickly" So, I expect the data will be more or less immediately sent down from the app when the user triggers it or when the app is in background, but it becomes obviously slow these days.
Viewed on Sep 07, there were 423 first_open on Sep 06.
Viewed on Sep 08, there were 1306 first_open on Sep 06.
Viewed on Sep 09, there were 0 first_open on Sep 08.
Viewed on Sep 12, there were 1092 first_open on Sep 08.
Usually, it takes about 24 hours for it to show up in the console. Note that analytics data has a possibility to arrive late because of the variability of network conditions. Analytics data is stored locally in the device, online or offline. When network connection becomes available, Firebase will batch the data and will attempt to upload it. As such, Firebase collect and process events that might arrive up to 3 days late. As a result, metrics for the last 3 days are in a state of flux until 3 days have elapsed. The data for yesterday and today might not have been reflected yet in the console. You could check this Firebase blog to know more about the delay in Analytics reporting.
Related
Is firebase generated server time stamp automatically converted into local time as I am getting the time stamp same as my local time or am I missing something?
_firestore.collection("9213903123").document().setData(
{
"title": title,
"message": message,
"deviceTimeStamp": DateTime.now(),
"serverTimeStamp": FieldValue.serverTimestamp(),
},
);
after running the above statement I can see both devicetimestamp, and serverTimeStamp are same.
But their is slight delay in their seocons.
Data In firestore...
deviceTimeStamp
8 August 2020 at 16:39:08 UTC+5:30
(timestamp)
message
"26"
serverTimeStamp
8 August 2020 at 16:39:16 UTC+5:30
title
"26"
The thing I am trying to do is basically ordering on the basis of date time and the user can see when he has created the notes, but if someone creates a note and stores it into firestore anywhere from the world(irrespective of location). Will, he/she gets their local time by using server timestamp(as I want this so can user see when they have added their document). ANd for safety, I want to use server time stamp so if a device is not in sync with the current time .
Firestore's FieldValue.serverTimestamp() creates and stores the timestamp in UTC Epoch time at the moment the request reaches the Firestore server.
Calling serverTimestamp() doesn't create a timestamp at the time it is invoked and doesn't rely on your user's device time or timezone. Instead, it creates what could be thought of as a placeholder for the date/time. This placeholder is only converted to a timestamp once the request is received by the Firebase server. As a result, the Firestore timestamp will always be at least slightly later than your client date/time (assuming the client time is perfectly synced.)
Using Firestore's timestamp should generally meet your goals of storing dates/times for users across the world in a consistent way, retrieving / sorting notes by creation time, and converting the timestamps into the user's local timezone client side. You may, however, want to handle things slightly differently for scenarios when your users are offline.
See Doug Stevenson's article for a helpful, more detailed explanation of Firestore timestamps.
I am attempting to publish events via FlutterAnalytics but I am experiencing very sporadic behaviour.
Using latest firebase_core and firebase_analytics packages
Using Firebase project on PAYG Blaze plan
Add pushing of events to BigQuery
Using vanilla flutter create project for testing
Downloaded and added google-services.json to android/app and android/app/debug folder
Added firebaseAnalytics.logEvent(name: 'testevent'); in onPressed where counter is incremented
Click button until counter reaches 100
Expect to see 100 events in Firebase Analytics but I see none.
Look in StreamView, after 5 minutes a part of them show up, alongside the automatically collected screen_view etc.
Look in DebugView (after activating adb) they show up instantly.
Look in Events tab, nothing
Look in BigQuery, nothing, not even tables created
They say events don't show up instantly, wait up to 24h, okay:
Wait 24h, no event in Events tab beyond the automatically collected ones
No BigQuery table generated
Wait 48h, no event showing up.
I then proceeded to create several other test firebase projects, with varying degrees of events showing up:
One project has 12 events out of 100 in BigQuery and 100 in Events tab
Another project has no events
Another project has 27 events in Events tab and 12 in BigQuery
Is anybody getting better mileage out of Firebase Analytics ? It cannot be a misconfiguration on my part on a vanilla project as then no events would show up, not this sporadic behaviour across all the projects.
since you are seeing varying levels of events logged, we need to determine if each of the event is sent to the server for processing. this can be checked by enabling the verbose mode.
adb shell setprop log.tag.FA VERBOSE
adb shell setprop log.tag.FA-SVC VERBOSE
adb logcat -v time -s FA FA-SVC
This will help you to verify if the event is logged or not immediately instead of waiting for 24-48 hours for the UI to show that.
If the events are not logged in the verbose mode, then you might want to rephrase your code to send 100 sequential events, if that is required. Another thought is like lots of same events from same user, are so quick and so they are packaged together for processing resulting in various count. ALways do verbose mode to ensure your events are created and sent as you wanted to analyze further.
I have an application that's been running since 2015. It both reads and writes to approx 16 calendars via a service account, using the Google node.js library (calendar v3 API). We also have G Suite for Education.
The general process is:
Every 30 seconds it caches all calendar data via a list operation
Periodically a student will request an appointment "slot", it first checks to see if the slot is still open (via a list call) then an insert.
That's all it does. It's been running fine until the past few days, where API insert calls started failing:
{
"code": 403,
"errors": [{
"domain": "usageLimits",
"reason": "quotaExceeded",
"message": "Calendar usage limits exceeded."
}]
}
This isn't all that special - the documentation has three "solutions":
Read more on the Calendar usage limits in the G Suite Administrator
help.
If one user is making a lot of requests on behalf of many users
of a G Suite domain, consider using a Service Account with authority
delegation (setting the quotaUser parameter).
Use exponential backoff.
I'm not exceeding any of the stated limits as far as I can tell.
While I'm using a service account, it isn't making a request on behalf of a user. The service account has write access to the calendar and adds the user as an attendee
Finally, I do not think exponential backoff will help, although I do not have this implemented. The time between a request to insert and the next insert call is measured in seconds, not milliseconds. Additionally, just running calls directly on the command line with a simple script produce the same problem.
Some stats:
2015 - 2,466 inserts, 186 errors
2016 - 25,747 inserts, 237 errors
2017 - 42,815 inserts, 225 errors
2018 - 41,390 inserts, 1,074 errors (990 of which are in the past 3 days)
I have updated the code over the years, but it has remained largely untouched this term.
At this point I'm unsure what to do - there is no channel to reach Google, and while I have not implemented a backoff strategy, the way timings work with this application, subsequent calls are delayed by seconds, and processed in a queue that sequentially processes requests. The only concurrent requests would be list operations.
The official document of Firebase Realtime profiler says:
The profiler tool logs all the activity in your database over a given period of time, then generates a detailed report.
But it doesn't tell the specific time like last 24 hours.
My database usage shows that on a particular day, bandwidth consumed is X so I want to specify a particular day or time duration like last 24 hours in Firebase Realtime database profiler >
Q1. Is it possible to specify the duration in profile like last 24 hours?
Q2. How does profiler work?
I think, profiler just scans some log and keeps writing/streaming the operations to user console unless user stops the the profiling tool. Correct me if I am wrong here.
Q1. Is it possible to specify the duration in profile like last 24
hours?
No, it's not possible to profile "last" hours. But you can profile the next 24. (I'll get to that on Q2)
Q2. How does profiler work?
What the profiler does is it logs all the operations happening on your database from the time you run the command until the time you stop it. When you run the command, the console will show you how many operations have been logged so far and you can use Enter to stop logging. It will then show you (or save it to a file if you prefer) speed and bandwidth reports.
But it also has an option to set the logging duration (in seconds). For example, if you want to log the next 24 hours you can use:
firebase database:profile -d 86400
But have in mind that logging only happens if the computer that started it is still on. This means you'll need to keep your computer on for the next 24h.
Every morning between 8 and 9 am CET my site shows this error:
Error Over Quota
This application is temporarily over its serving quota. Please try again later.
although billing is enabled and the site has been running for many months now. On the old billing status page, there's a setting for Maximum Daily Budget (Set this to handle peak traffic and to buffer against sudden traffic surges.) which is set to $0.00, but even if I change that to e.g. $10.00, it still shows the 503 error, so it seems this has nothing to do with it.
The new billing page looks like this:
It happens every morning between 7 and 8 am CET, so that would be around midnight PST which would at least indicate that it still might have something to do with billing?
Here's how the external monitoring system shows the outages, i.e. multiple outages every morning and then no problems for the rest of the day.
The Google Developers Console Overview page Errors by status code also shows the 503 error in green.
If I look at the monitoring logs most of the 503 errors between 7 and 9am for the following pages:
/
/wp-cron.php
And then there are some 500 errors, e.g. at 8 am
08:07:08.092 ... [26/Nov/2014:23:07:08 -0800] "GET / HTTP/1.1" 500 0 - "Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)" "www.coworking-radolfzell.de" ms=921 cpu_ms=1042 loading_request=1 exit_code=108 instance=00c61b117c9ad93b9da1f63314065ff8f4188095 app_engine_release=1.9.16
08:07:08.092 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.
08:07:08.092 Process terminated due to exceeding quotas.
The (new) quota details page says Quotas are reset every 24 hours. Next reset: 1 hours and now it's 8:30 am CET. All of the listed resources are rated Okay.
If I go to the old Quota Detailsp page, though, I see that my requests' Frontend Instance Hourshave reached 100% and are rated Limited.
So I went back to the new console under Compute / App Engine / Settings which showed Your budget today is $10.00. Effective tomorrow, you will be using only free quota. which I now increased to a daily budget of USD 5.
My site now still shows the 503 error, but hopefully this will be the solution. I should be able to tell in 24 hours, shouldn't I?
If anyone from Google App Engine is reading this, there might be some inconsistencies between the old and new panels that should probably be fixed.
My problem has been solved by increasing the daily budget vom 0 to 5, although it took a couple of hours to take effect. We haven't had any notifications from the monitoring system, so it seems to be all fine now.